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Chapter  I 
Introduction 


The  rapid  developments  in  computer  science  and  operations  research  tech¬ 
niques  have  spawned  several  technical  revolutions  in  the  past  30  years.  Multi¬ 
echelon  inventory  theory  is  one  of  these  areas.  An  1930,  only  a  few  limited  results 
from  queuing  theory  were  available  to  assist  inventory  managers.  Today,  com¬ 
puterized  systems  exist  capable  of  computing  jointly  optimal  inventory  policies  for 
thousands  of  items  stocked  at  perhaps  several  hundred  locations,  considering 
assembly /sub-assembly  relationships,  and  multi-echelon  logistics  support  systems. 
Several  of  these  models  have  become  major  components  of  Air  Force  Logistics 
Command  (AFLC)  data  systems,  and  several  other  models  have  been  proposed  for 
implementation.  Application  areas  covered  by  these  systems  include  planning  and 
budgeting,  initial  provisioning,  replenishment,  and  distribution. 

The  Recoverable  Item  Management  Evaluator  (RIME)  is  a  Fortran-based 
simulation  model  for  evaluating  the  relative  cost-effectiveness  of  analytic  optimi¬ 
zation  procedures  proposed  for  use  in  AFLC  recoverable  item  management 
systems.  Major  features  of  RIME  include: 

1.  Actual  Air  Force  demand  drives  the  model.  The  world  is  never 
stationary  but  changes  with  world  events  and  with  the  introduction  of  new  weapon 
systems.  Hence,  RIME  uses  actual  Air  Force  demand  histories  to  represent  the 
demand  processes  and  recoverable  item  flows  of  recoverable  items.  This  is  in 
contrast  to  the  use  of  tjie  a  priori  assumptions  embedded  in  analytical  multi¬ 
echelon  inventory  models. 
fvhMttn  Inventory  InooHs, 


2.  Parameter  values  are  based  on  statistical  estimates.  The  parameters 
of  underlying  demand  processes  are  never  known  with  certainty,  but  must  be 
estimated  from  statistical  data  describing  past  demands.  In  RIME,  we  utilize  the 
same  statistical  estimation  formulas  used  in  Air  Force  data  systems  to  determine 
demand  rates,  NRTS  rates,  and  condemnation  fractions.  This  information  is 
recomputed  on  a  quarterly  basis,  in  a  manner  similar  to  that  of  the  D041 
Recoverable  Item  Requirements  Computation  System. 

3.  Dynamic  system  interactions  are  modeled.  The  world  is  not  station¬ 
ary,  but  changes  as  actual  Air  Force  demand  changes.  These  changes  produce 
temporary  imbalances  in  the  Air  Force  supply  system,  and  subsequent  management 
actions  to  correct  these  imbalances.  RIME  simulates  these  effects.  Consequently, 
RIME  describes  the  dynamic  period-by-period  interactions  which  cannot  be  repre¬ 
sented  in  the  stationary  assumptions  of  current  analytical  multi-echelon  inventory 
models. 

Of  course,  RIME  is  also  only  a  model,  and  is  thus  only  an  approximation  of  the 
real  world.  However,  we  believe  that  RIME  is  a  sufficiently  rich  description  of  Air 
Force  supply  systems  to  serve  as  a  convenient  test  bed  for  comparing  alternate 
analytical  inventory  management  policies. 

This  report  presents  a  detailed  description  of  RIME.  Volume  I  describes  the 
major  concepts,  organization,  and  input/output  features  of  the  model,  while 
Volume  II  provides  detailed  narratives  of  each  RIME  subroutine  as  well  as  listings 
of  the  FORTRAN  source  code.  On  the  other  hand,  reference  1  describes  the  use  of 
RIME  in  a  study  of  the  relative  cost-effectiveness  of  several  computation  methods 
proposed  for  use  in  Air  Force  recoverable  item  management.  Throughout  this 
report,  we  assume  the  reader  is  familiar  with  Sections  I-IV  of  Reference  1. 


An  Overview  of  the  Recoverable  Item  Management  Evaluator  System 

The  major  components  of  the  Recoverable  Item  Management  Evaluation 
System  are  shown  in  Figure  1-1.  At  the  heart  of  the  system  is  the  RIME  Simulator. 
The  Simulator  simulates  a  multiple  echelon  recoverable  item  inventory  system,  and 
provides  the  means  for  estimating  the  procurement  dollars  and  supply  support 
measures  associated  with  given  sets  of  inventory  management  levels. 

Figure  1-1  illustrates  the  major  components  in  the  RIME  system.  As  shown  in 
the  figure,  the  RIME  System  has  four  major  components.  The  Data  Extract  System 
is  used  to  obtain  LRU/SRU  data  from  the  DOti  Data  Bank,  and  to  manipulate  this 
information  into  the  form  required  for  input  to  the  RIME  System.  Ve  call  this  data 
file  the  "Master  Data  Set."  The  Exogenous  Event  Generator  translates  the 
aggregate  historical  demands  obtained  from  the  Master  Data  Set  into  a  detailed 
list  describing  LRU  and  SRU  reparable  generations  and  associated  requisition, 
repair,  and  NRTS  activities  by  base.  These  detailed  lists  are  recorded  on  the 
Exogenous  Event  File,  and  represents  a  major  input  to  the  RIME  Simulation  Model. 

The  Stock  Level  Computation  system  also  uses  the  Master  Data  Set  as  input. 
This  system  computes  inventory  levels  for  each  time  period  in  the  simulation 
horizon  for  each  item  in  the  Master  Data  Set.  By  varying  the  input  parameters, 
the  system  can  compute  stock  levels  vaing  the  METRIC,  MOD-METRIC,  Variable 
Safety  Level  (VSL),  or  AFLCR  57-27  computational  methodologies,  as  well  as 
several  variations  of  these  methods.  As  shown  in  the  figure,  different  computa¬ 
tional  methods  may  be  used  in  initial  provisioning  calculations  from  those  used 
during  the  replenishment  phase  of  an  item's  life  cycle.  The  individual  item  stock 
levels  computed  by  this  system  are  stored  in  a  "Levels^  File.  This  File  provides  the 
second  major  input  to  the  RIME  Simulation  Model. 


EXOGENOUS  EVENT  GENERATOR 


Figure  i-l. 
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The  heart  of  the  RIME  system  is,  of  course,  the  simulation  model  itself.  This 
model  inputs  the  detailed  list  of  historical  reparable  generations  and  associated 
exogenous  events,  as  well  as  sets  of  levels  computed  by  the  Stock  Levels  Computa¬ 
tion  system.  It  then  uses  simulation  techniques  to  evaluate  how  well  the  given 
stock  levels  would  have  performed  in  managing  the  events  described  in  the  Event 
File. 

Outputs  from  the  simulation  model  include:  (a)  detailed  statistics  of 
inventory/ repair  activities  by  location,  item  type,  and  time  period,  (b)  a  short-form 
report  which  displays  totals  of  six  mayor  statistics  summed  over  all  simulated 
periods,  (c)  results  for  each  replication  for  each  LRU/SRU  group,  and  (d)  printouts 
to  assist  in  the  debugging  of  extensions  to  the  RIME  model. 

Chapters  I  through  IV  of  Reference  1  provide  a  general  overview  of  the  RIME 
model,  and  we  assume  that  the  reader  is  familiar  with  this  material.  In  this  report, 
we  provide  detailed  description  of  each  of  the  components  of  the  RIME  system.  In 
Chapter  II,  we  review  the  mayor  concepts  employed  in  the  RIME  Simulation  Model. 
This  Chapter  describes  the  numbering  systems  used  to  keep  track  of  inventories  at 
different  stocking  locations,  methods  of  describing  the  passage  of  times  within  the 
simulated  model,  the  specific  events  simulated  by  the  RIME  system,  and  a 
description  of  the  detailed  statistics  collected  by  the  Simulation  Model.  Chapter 
ID  provides  a  detailed  description  of  the  Events  Generator.  This  Chapter  describes 
methods  for  generating  exogenous  events  and  the  computer  prog-ams  used  to 
implement  the  event  generation  activities.  Chapter  IV  describes  the  Levels 
Computation  System.  This  Chapter  describes  the  network  of  computer  programs 
involved  in  simulating  specific  combinations  of  initial  provisioning  and  replenish¬ 
ment  calculation  methods.  Finally,  Chapter  V  provides  instructions  for  individuals 


interested  in  utilizing  the  current  RIME  version.  This  chapter  describes  the  steps 
involved  in  simulating  specific  inventory  management  policies,  and  also  describes 
output  reports  produced  by  the  RIME  Simulation  Model. 


Chapter  II 

Major  Model  Concepts 


To  understand  the  detailed  program  structure  of  RIME,  one  must  possess  a 
clear  understanding  of  (a)  the  numbering  system  used  to  keep  track  of  the  stock 
status  of  each  simulated  LRU  and  SRU  at  each  at  the  possible  stocking  locations, 
(b)  the  methods  used  to  simulate  the  passage  of  time,  (c)  the  events  that  simulate 
significant  inventory  system  transactions,  and  (d)  the  data  files  that  record  current 
system  status  and  that  measure  simulated  performance.  These  major  elements  are 
the  subject  of  this  chapter. 

Stock  Keeping  Unit  Conventions 

In  RIME,  each  LRU  and  SRU  may  be  stocked  at  possibly  several  stocking 
locations.  As  discussed  in  Chapter  1,  the  RIME  model  represents  several  types  of 
stocking  locations,  including  a  depot  level  maintenance  facility,  several  operating 
bases,  and  an  aircraft  overhaul  facility.  In  simulating  these  systems,  it  is 
necessary  to  keep  track  of  the  on-hand  and  on  order  stock  for  each  stock  number 
at  each  of  the  possible  locations.  We  use  the  term  Stock  Keeping  Unit  (SKU)  to 
refer  to  the  specific  number  assigned  to  a  given  stock  number- geopaphic  location 
pair. 

Figure  II- 1  illustrates  the  assignment  of  Stock  Keeping  Unit  Nunbers  for  an 
LRU/SRU  family  consisting  of  an  LRU  and  two  SRUs  that  are  stocked  at  three 
operating  bases.  As  shown  in  the  figure,  inventories  of  the  LRU  at  the  Depot  Level 
Maintenance  Facility  are  always  assigned  a  Stock  Keeping  Unit  number  of  1.  Stock 
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STOCK-KEEPING  WIT  NUMBERING  CONVENTIONS 

FOR 

THREE  BASES  AND  TWO  SRUS 


Sample  Data  Set 


SRU  #1 


SRU  92 


Then 


Stock  Keeping 
Unit 


NBASES 

NSRU 

NSTKU 


Description 


Consider  a  parts  family 
consisting  of  an  LRU  and 
two  SRUs*  Suppose  each 
item  is  stocked  at  three 
bases,  plus  an  overhaul 
facility  plus  a  Depot 
Level  Maintenance  Facility 


(NSRU+1) * (NBA6ES+2) 
(3)  * (5) 

IS 


LRU  at  Depot  Level  Maintenance  Facility 

LRU  at  Base  91 

LRU  at  Base  92 

LRU  at  Base  93 

LRU  at  Overhaul  Facility 

SRU  91  at  Depot  Maintenance  Facility 

SRU  91  at  Base  91 

SRU  #1  at  Base  92 

SRU  #1  at  Base  93 

SRU  91  at  Overhaul  Facility 

SRU  92  at  Depot  Level  Maintenance  Facility 

SRU  #2  at  Base  91 

SRU  92  at  Base  92 

SRU  #2  at  Rase  #3 

SRU  92  at  Overhaul  Facility 


n-3 


Keeping  Unit  numbers  of  2,  3,  t ’d  $  are  assigned  to  inventories  of  the  LRU  at  base 
locations  1,  2,  and  3  respectively.  Finally,  an  SKU  of  5  is  assigned  to  inventories  of 
the  LRU  at  thj  Aircraft  Overhaul  Facility. 

Stock  Keeping  Unit  numbers  for  the  SRUs  follow  a  similar  pattern.  Conse¬ 
quently,  an  SKU  of  6  represents  inventories  of  SRU  #1  at  the  Depot  Maintenance 
Facility,  while  the  SKUs  of  7,  8,  and  9  represents  inventories  of  this  SRU  at  Bases 
1,  2,  and  3,  respectively.  Finally,  an  SKU  of  10  is  assigned  to  inventories  of  SRU 
#1  at  the  Aircraft  Overhaul  Facility.  As  shown  in  Figure  II- 1,  a  similar  pattern  is 
used  in  assigning  Stock  Keeping  Unit  nunbers  to  the  inventories  for  SRU  #2. 

In  RIME,  the  variable  NSRU  denotes  the  number  of  SRUs  that  are  components 
of  the  LRU,  and  the  variable  NBASES  denotes  the  total  number  of  base  locations. 
Hence,  counting  the  LRU  there  are  (NSRU+1)  distinct  stock  numbers  simulated  in 
RIME,  and  each  of  these  may  be  slocked  at  any  of  the  NBASES  bases  in  addition  to 
being  stocked  at  the  depot  and  the  overhaul  facility.  Hence,  the  total  number  of 
stock  keeping  units  needed  to  keep  track  of  inventories  by  location  is  (NSRU  +  1)* 
(NBASES  +2). 


The  Timing  Mechanism 


The  fundamental  modeling  concept  employed  in  RIME  is  that  of  an  "event." 
An  event  is  a  specific  point  in  time  in  which  the  state  or  condition  of  the  system 
changes  or  potentially  changes.  For  example,  the  amount  of  stock  on  hand  changes 
if  a  requisition  is  received  and  goods  are  shipped  to  fill  the  demand.  Hence, 
receipt  of  a  customer  requisition  is  an  event.  Other  events  that  may  change  the 
amount  of  on  hand  stock  include  delivery  of  a  replenishment  order  by  a  vendor  of 
the  supply  system  and  the  return  of  serviceable  assets  from  a  customer. 


In  simulating  any  system,  two  dstinct  categories  of  events  may  be  identified. 
Exogenous  events  are  events  that  are  "caused  by"  activities  that  are  external  to 
the  system;  they  are  the  stimuli  that  cause  the  system  that  react  in  some  manner. 
On  the  other  hand,  endogenous  events  are  caused  by  the  reaction  of  the  simulated 
system  to  either  exogenous  events  or  other  endogenous  events.  For  example,  in 
RIME  reparable  generations  of  LRUs  and  SRUs  and  associated  demands  for 
serviceable  replacements  are  treated  as  exogenous  events  —  events  that  drive  the 
entire  simulated  repair/ resupply  system.  The  shipment  of  goods  and  the  placement 
of  replenishment  orders  are  examples  of  endogeuous  events.  They  are  "caused  by" 
the  LRU  and  SRU  demands  which  deplete  on  hand  stocks. 

In  RIME,  a  number  of  events  are  treated  as  exogenous  events;  these  are: 

1.  LRU  and  SRU  reparable  generations,  and  associated  condemnation, 
serviceable  return,  repair,  and  NRTS  actions  whose  timing  may  be 
determined  from  the  timing  of  the  reparable  generation  event. 

2.  The  computation  of  initial  provisioning  stock  levels. 

3.  The  calculation  of  replenishment  stock  levels. 

Because  of  the  large  voltme  of  data  involved  in  simulating  an  LRU  and  all  of 
its  SRUs  simiitaneously,  ail  exogenous  events  for  a  given  LRU/SRU  family  are 
generated  as  a  preprocessing  step  and  recorded  on  magnetic  tape.  This  list  of 
events  is  called  the  "Exogenous  Event  File  (EEFF.  Events  recorded  on  this  file  are 
sorted  in  time  sequence.  Consequently,  the  time  interrelationships  of  exogenous 
events  may  be  determined  by  sequentially  reading  the  EEF.  On  the  other  hand,  the 
time  interrelationships  of  Exogenous  Events  are  maintained  through  the  use  of  a 
Future  Events  List  (FED  that  is  updated  dynamically  as  part  of  the  RIME 
simulation  process.  Ve  will  dscuss  each  of  these  files  and  illustrate  their  use  later 
in  this  chapter. 


RIME  Events 
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In  the  Recoverable  Item  Management  Evaluator,  three  categories  of  events 
are  used  to  simulate  recoverable  item  flows.  They  are: 


a.  Material  flow  events  -  describing  the  receipt  of  a  customer  requisition, 
delivery  of  replenishment  order,  the  return  of  serviceable  assets,  the 
generation  of  unserviceable  assets,  and  associated  repair,  condemnation, 
or  NRTS  actions. 

b.  Management  action  events  -  describing  important  management  decision 
points.  The  calculation  of  control  levels,  status  reviews  to  determine 
what  reorder,  termination,  or  disposal  actions  are  appropriate,  and  the 
establishment  of  budgets  and  procurement  guidelines  are  examples  of 
these  events. 

c.  Simulation  bookkeeping  events  -  events  to  collect  time- valued  statistics, 
to  collect  intermediate  statistics  for  debugging  purposes,  and  to  signal  the 
end  of  simulation. 


At  present,  twenty  possible  events  are  included  in  the  RIME  model.  These 
events  are  listed  in  Table  II- 1.  In  RIME,  there  is  a  separate  FORTRAN  subroutine 
to  describe  how  each  event  changes  the  state  of  the  system,  and  to  record 
associated  performance  statistics.  Table  0-1  also  presents  the  subroutines 
associated  with  each  event  and  the  definitions  of  the  parameters  IP3,  IP4,  and  IP5 
used  in  scheduling  the  respective  events. 


Event  Parameters 

In  RIME,  each  event  —  whether  exogenous  or  endogenous  —  is  represented  by 
five  data  elements.  These  are: 

ITIME  -  The  time  the  event  is  scheduled  to  occur. 

ITYPE  -  The  event  type. 

IP3,  IP4,  JP9  -  Three  parameters  which  further  define  the  natire  of  the 


event 


RIME  Events 


Special  Statistics  N  SSTAT  KEND  KEND  KEND 

Endogenous  Requisition  N  DEMPAR* 

Generation 

Trace  N  MAIN 


of  resupply,  where  NSKU=0  denotes  receipt  of  a  vendor  shipment. 

events  are  not  implemented  in  the  current  RIME  model.  However,  these  program  names  are  reserved 


Table  11-1  (Confd) 

Event  X=Exogenous  Event 

Type  Event  N= Endogenous  Routine  _ Parameters 


n-io 


As  shown  in  Table  II- 1,  event  type  1  represents  the  receipt  of  a  requisition  from  a 
customer  of  the  supply  organization.  This  event  may  be  either  exogenous  (X)  or 
endogenous  (N),  depending  upon  the  origin  of  the  requisition  request.  In  simulating 
type  1  events,  subroutine  REQ  is  used.  Further,  the  three  parameters  associated 
with  a  type  1  (requisition)  event  are  defined  as  follows: 

IP3  =  The  Stock  Keeping  Unit  Nunber  N  associated  with  the  inventory  item 
bang  requisitioned. 

IP4  =  The  number  of  units  (IQTY)  being  requisitioned. 

IP5  =  The  priority  of  the  requisition.  Definitions  of  the  other  event  types 
and  the  associated  FORTRAN  routines  may  be  seen  by  further  inspection 
of  Table  II- 1. 

Timing  Conventions  and  Initial  Events 

To  simplify  programming  and  analysis  tasks,  it  was  desirable  to  establish 
timing  conventions  that  differ  slightly  from  values  associated  with  the  Gregorian 
calendar.  Specifically,  RIME  assumes  that  each  day  consists  of  100  Time  Units 
(TU).  Days,  weeks,  months,  and  years  are  then  assumed  to  be  related  as  shown  in 
Table  II -2.  Since  the  values  are  used  repeatedly  throughout  a  simulation  run, 
specific  COMMON  variables  are  established  for  each  of  these  time  units.  Values  of 
these  variables  are  initialized  by  subroutine  INITAL  at  the  beginning  of  each  RIME 
simulation  run  Other  timing  variables  that  are  initalized  by  subroutine  INITAL  are 
shown  in  Table  II-3. 

All  RIME  events  may  be  classified  as  either  (a)  scheduled  events,  (b)  random 
events,  or  (c)  dependent  events.  Scheduled  events  are  events  with  a  specific 


TABLE  II-2 


Time 

Intervals 

Basic 

Value 

Time  Conventions 

Time  in 

TU's 

Variable 

1  Day 

100  TU's 

= 

ITDAY 

1  Week 

7  Days 

700  TU’s 

= 

ITWEEK 

1  Month 

4  Weeks 

2,800  TU’s 

3 

ITMNTH 

1  Quarter 

3  Months 

8,400  TU’s 

= 

ITQTR 

1  Year 

4  Quarters 

33,600  TU's 

3 

ITYEAR 

NOTES 

It  is  assumed  that  1  Day  =  100  Time  Units  (TVs),  and  each  Time  Variable  is 
expressed  in  TV's. 


TABLE  n-3 


Variable 

IQTRND 

ITINV 

ITIME 

ITLEVL 

IDLEVL 

ITDIV* 

IDDIV* 

ITFOR* 

IDF  OR* 

ITHQ* 

IDTHQ* 

ISTOP 

ISTAT 

IDSTAT 

INQTR 


1 

Timing  Vriablcs  Established  in  IN1TAL 

Definition 

clock  time  that  marks  end  of  current  quarter 
number  of  current  quarter 

current  simulation  dock  time  (100  Time  Units  =  1  day). 
At  the  beginning  of  a  simulation  run,  ITIME  =  0. 

dock  time  of  the  next  computation  of  stock  levels 

time  interval  between  stock  level  computation 

dock  time  of  the  next  division  level  review 

time  interval  between  division  level  reviews 

time  of  the  next  update  of  demand  history  records  (Event 
type  9) 

time  between  history  file  updates 

time  of  next  Headquarters  USAF  stock  fund  budget  review 

time  between  Headquarters  USAF  budget  reviews. 

dock  time  that  simulation  is  to  be  stopped 

dock  time  for  activating  statistics  collection  routines 

time  interval  between  statistics  collection 

number  of  quarters  to  be  simulated 


NOTES 

*These  variables  are  not  used  in  the  current  verision  of  RIME.  However,  these 
variable:  names  are  reserved  for  future  extensions  of  the  model. 
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schedule  of  occurrence  times.  For  example,  initial  provisioning  calculations  (event 
type  20)  occur  at  the  beginning  of  each  simulation  run,  and  leveling  events  (event 
type  6)  occur  at  the  end  of  every  quarter.  On  the  other  hand,  reparable 
generations  (event  type  14)  and  serviceable  returns  (event  type  4)  are  random 
events— the  time  of  occurrence  of  these  events  is  not  known  in  advance.  Finally, 
the  delivery  of  a  replenishment  order  (event  type  2)  is  a  dependent  event  since  the 
time  of  delivery  is  dependent  upon  earlier  management  reordering  decisions. 
Dependent  events  are  caused  by  the  occurrence  of  an  associated  random  or 
scheduled  event.  Hence,  requisitions  for  serviceable  assets  (event  type  1)  to 
replace  flight  line  reparable  generations  are  dependent  events,  since  the  requisition 
for  a  serviceable  unit  was  caused  by  the  flight  line  failure. 

In  RIME,  the  first  occurrence  of  each  scheduled  event  is  created  by  subroutine 
INITAL;  that  is,  INITAl  puts  an  entry  on  the  Future  Events  List  for  each  scheduled 
event  at  the  beginning  of  a  simulation  run.  Subsequent  scheduled  events  are  put  on 
the  Future  Events  List  each  time  a  new  scheduled  event  occurs.  For  example,  at 
the  conclusion  of  a  Leveling  event  (event  type  6),  a  subsequent  type  6  event  is 
scheduled  to  occur  one  quarter  in  the ♦  jture. 

Specific  values  for  the  time  between  scheduled  events  are  set  in  subroutine 
INITAL.  Table  0-3  defines  specific  time  variables  initialized  in  this  routine. 

The  Futire  Events  List 

The  secpendng  of  endogenous  events  through  time  is  controlled  by  a  Future 
Events  List  (FED.  The  FEL  is  a  list  of  all  endogenous  events  scheduled  to  occur  at 
some  future  (simulated)  time.  For  each  event  on  the  list,  the  following  values  are 
recorded. 


IT1ME 


=  The  time  the  event  is  scheduled  to  occur. 


ITYPE  =  The  event  type  (code). 

IP3,  IP4,  IP5  =  Event  parameters. 

Struct  it  ally,  t^e  *s  a  linked  list  in  ascending  order  by  scheduled  event 

time.  In  such  a  list,  new  entries  to  the  list  are  inserted  in  a  previously  unused  data 
storage  location,  and  pointers  are  used  to  indicate  the  correct  sequencing  of  the 

entry  in  the  list.  The  major  variables  associated  with  this  list  are  shown  in  Table 
0-4. 

At  the  begimning  of  each  simulation  run,  subroutine  INFEL  is  called  to 
initialize  the  pointers  and  other  control  variables  associated  with  the  FEL. 
Scheduled  events  are  then  entered  and  removed  from  the  Futire  Events  List  by 
subroutine  ENTER  and  REMOVE,  respectively.  New  events  are  inserted  into  the 
FEL  by  the  following  CALL  statement: 

CALL  ENTER  (rTIME,  ITYPE,  IP3,  IP4,  IP 5) 
where  ITIME,  ITYPE,  IP3,  IP4,  IP5,  are  as  defined  above.  When  subroutine  ENTER 
is  called,  the  new  event  data  is  recorded,  and  the  list  pointers  are  updated  to  insert 
the  new  event  in  the  proper  time  sequence. 

Events  are  removed  from  the  Futire  Events  List  by  subroutine  REMOVE;  the 
CALL  statement  takes  the  form 

CALL  REMOVE  (ITIME,  ITYPE,  IP3,  IP4,  IP5) 

and  the  calling  parameters  are  as  defined  above.  Subroutine  REMOVE  removes  the 
first  entry  from  the  FEL  and  updates  the  pointers  accordingly;  that  is,  it  deletes 
the  list  entry  with  the  smallest  (earliest)  scheduled  clock  time  from  the  FEL,  and 
returns  the  corresponding  data  values  throi^h  the  parameter  list. 


TABLE  0-4 


NFEMAX 

NENTRY 

ILOCFE(J) 

K 

JTIMEOO 

3TYPE(K) 

JPOINT(K) 

3FSN(K) 

JQTYOO 

JPRIOR,(K) 


NFIRST 

NTIME 

NLOC 


Future  Events  Lift  Variables 

=  maximum  number  of  entries  on  Futire  Events  List 

s  number  of  entries  on  the  Futire  Events  list 

*  number  of  3th  unused  data  location  in  the  Futire  Events 
file 

a  list  index 

a  dock  time  of  event  transaction 
a  event  type 

a  pointer  to  next  transaction  in  list 
a  stock  number  identification* 
a  quantity  involved* 
a  priority,*  where 

(1-high  priority 
2-low  priority 

a  location  of  first  transaction  of  chain 
a  time  of  earliest  transaction  on  list 
a  location  of  last  transaction  placed  on  the  chain 


*if  applicable 


Subroutine  WRIFEL  is  another  routine  associated  with  the  Future  Events  List. 
In  debugging  new  RIME  models,  it  is  sometimes  desirable  to  write  out  the  entire 
Future  Events  List  at  selected  times  within  a  simulation  run.  Subroutine  WRIFEL 
performs  this  function. 

To  illustrate  the  use  of  the  Future  Events  List  consider  the  LRU  family 
Illustrated  in  Figure  0- 1.  Suppose  that  as  a  result  of  an  LRU  failure  at  base  #2,  a 
high  priority  requisition  for  a  serviceable  replacement  Is  submitted  to  the  base 
supply  organization.  In  this  case, 

ITYPE  *  1  (The  Event  Code  for  a  requisition  event,  as  will  be  discussed 
later). 

IPS  «  3  (The  stock-keeping  unit  number  for  LRU  Inventories  at  base  #2K 

IPS  si  (The  number  of  units  being  requisitioned). 

P)  ml  (This  indicates  a  high  priority  requisition.  For  requisition  ever**, 

IP3  •  1  denotes  a  high  priority  requisition,  while  IPJ  *  2  denotes 
a  low  priority  requisition.  Por  other  event  codes,  this  parameter 
has  other  meanings.) 

Suppose  this  requisition  is  to  occur  at  tha  beginning  of  the  9th  day  of  the 
dedadon.  Than  uting  tha  time  conventions  illustrated  in  Tabit  tt-2, 

mm»9oo 

since  there  are  100  Time  Units  in  each  slmulatad  day,  and  this  event  is  to  occur  at 
the  beaming  of  the  ninth  day. 

T H*  particular  event  may  then  be  scheduled  (l.e.,  put  on  the  Put  ire  Events 
List)  by  setting  each  of  tha  above  variables  as  shown,  and  than  using  the  FORTRAN 
esll  statements 


CALL  ENTER  OTIME,  ITYPE,  IPS,  IPO,  IP*). 
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Wh»n  tho  simulated  dock  time  eventually  rtachss  900  time  units,  the  above 
•vent  diU  would  bo  removed  from  tho  PEL  and  an  appropriate  subroutine  eodd  be 
called  to  simulate  tho  actions  which  result  from  receipt  of  this  requisition. 

Subroutine  EVNTSi  Tho  Event  Scheduler 

The  scheduling  of  spedflc  exogenous  and  endogenous  events  is  controlled  by 
Subroutine  EVNTS.  The  general  logic  of  this  routine  are  illustrated  in  Figure  1-2. 
As  shown  In  the  figure,  subroutine  EVNTS  first  initializes  the  pseudo-random 
men  bar  generator  and  the  Future  Event!  List,  and  then  reads  in  data  describing  the 
LRU/SRU  family  currently  being  simulated.  This  Is  dona  by  calls  to  subroutines 
RANDU,  IN  IT  A  L  and  1N1TM2,  respectively.  The  routine  then  Inspects  the  meet 
Imminent  events  (that  Is,  the  events  with  the  lowest  scheduled  dock  time)  on  both 
the  Exogenous  Event  File  (EEF)  and  the  Future  Event  List  (FED.  It  then  removes 
the  event  with  the  lowest  scheduled  dock  time  from  the  appropriate  list .  end  calls 
the  subroutine  assodated  with  that  event.  For  example.  If  the  event  with  the 
lowest  scheduled  time  is  a  type  1  event,  subroutine  REQ  is  called.  The  routines 
assodated  with  eadh  event  type  are  defined  In  Table  n-1.  These  event  routines 
update  the  status  of  the  system  and  work- in-process  inventories  «o  reflect 
occurrence  of  the  event.  In  addition,  the  event  routines  update  appropriate 
performance  statistics.  Some  of  the  events  also  cause  additional  endogenous 
events  to  be  scheduled.  If  this  occurs,  subroutine  ENTER  is  called  to  place  the 
newly- created  event  on  the  FEL.  For  example,  when  a  stock  level  computation 
event  (Event  Type  6)  occurs,  subroutine  LEVEL  is  called  to  compute  new  stock 
levels  for  etch  LRU  and  SRU  at  each  stocking  location.  At  the  oondusion  of  its 
calculations,  subroutine  LEVEL  calls  subroutine  ENTER  to  schedule  the  next  stock 
level  computation  event. 


Subroutine  EVNTS 


I 


Initialize  the  random  number  generator* 
the  Future  Events  List*  and  LRU/SRU 
data  arrays 
CALL  RANDU 
CALL  ZNITAL 
CALL  INITM2 


Yes 


Figure  II- 2.  Eyent  Scheduling  in  Subroutine  KVNTS 


When  an  End-of-Run  Event  (Event  Code  10)  is  encountered,  Subroutine  EVNTS 
returns  to  the  MAIN  program.  Otherwise,  the  routine  again  scans  both  the 
exogenous  event  file  and  the  updated  PEL,  and  identifies  the  particular  event  with 
the  lowest  dock  time.  This  event  is  then  removed  from  the  appropriate  list  and 
the  process  continues  until  a  End-of-Run  Event  is  eventually  encountered. 
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Data  Files 

A  large  number  of  data  elements  are  required  to  operate  any  computer 
simulation  model,  and  RIME  is  no  exception.  The  major  categories  o f  data 
associated  with  RIME  are  illustrated  in  Figure  n-3.  As  shown  in  the  Figure,  RIME 
data  elements  may  be  logically  classified  into  one  of  the  following  files: 

1.  Exogenous  Event  File  (EEF). 

2.  Future  Events  List  (FEL). 

3.  System  Characteristics  File. 

4.  Waiting- for- Parts  File. 

5.  Item  Data  File. 

6.  Stock  Level  File. 

7.  Backorder  File. 

8.  Simulation  Counters  and  Flags  File. 

9.  Performance  Statistics  File. 

The  Exogenous  Event  File  and  Future  Events  List  have  been  dscussed  earlier. 
Let  us  now  consider  the  contents  of  each  of  the  remaining  data  files. 

System  Characteristics  File 

The  Systems  Characteristics  File  contains  data  elements  that  define  the 
system  as  a  whole.  The  set  of  items  to  be  included  in  a  RIME  simulation  run,  the 
number  of  operating  bases  to  be  simulated,  and  the  number  of  historical  data 
periods  available  are  examples  of  data  elements  in  this  file.  This  information  is 
provided  primarily  through  inputs  of  file  05.  Table  II-5  defines  the  major  variables 
contained  in  this  logical  data  file.  Specific  data  elements  input  through  this  file 
will  be  dscussed  in  detail  in  Section  VL 
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FIGURE  H-3 

Logical  Data  Piles  in  RIME 


TABLE  D-5 


N30B 

NBASES 

NSRU 


System  Characteristics  File 


Last  assigned  job  number.  N30B  is  initially  set  to  1001,  and  is 
incremented  each  time  an  exogenous  event  is  created. 

Number  of  bases,  not  counting  the  depot  or  the  overhaul 
facility.  Hence,  the  total  number  of  stocking  locations  equals 
NBASES+2. 

Number  of  SRU's  in  the  LRU 

Number  of  stock  keeping  units,  which  equals  (NBASES+2)* 
(NSRU+1) 


NITEM 
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Work-In-Process  File 

To  repair  an  unserviceable  LRU,  it  may  be  necessary  to  remove  and  replace 
possibly  several  of  the  LRU's  components.  When  this  situation  occurs,  a  "Wait- 
for-Parts"  event  (event  type  =  16)  is  scheduled,  and  an  appropriate  entry  is  made  to 
the  Work-In-Process  File.  Table  0-6  illustrates  the  data  elements  contained  in 
this  file. 

The  GASP  Simulation  routines  FILEM  and  RMOVE  are  used  to  enter  and 
remove  entries  in  the  Work-in-Process  File,  and  the  Subroutine  INGASP  is  used  to 
initialize  the  appropirate  GASP  file  variables.  INGASP  is  called  by  Subroutine 
1NITAL  at  the  beginning  of  each  RIME  simulation  replication. 

A  detailed  description  of  the  GASP  file  system  and  its  associated  routines  is 
presented  by  A.A.B.  Pritsker  (The  GASP  IV  Simulation  Language.  3ohn  Wiley  and 
Sons,  New  York,  1974),  and  will  not  be  discussed  further  in  this  report. 

Item  Data  File 

The  item  data  file  contains  information  specifically  related  to  each  item  being 
simulated.  An  item's  unit  cost,  its  current  level  of  on-hand,  on-order  and 
work- in- process  stocks,  and  its  control  levels  (e.g.,  reorder  level,  support  level, 
termination  level,  or  retention  level)  are  examples  of  this  type  of  data.  Table  H-7 
presents  a  detailed  list  of  information  items  which  are  contained  in  this  file.  As 
shown  in  Tahle  D-7,  the  item  data  file  contains  several  subcategories  of  informa¬ 
tion.  These  define  (a)  specific  physical  and  management  characteristics  of  the 
item,  (b)  data  describing  the  stock  status  of  the  item,  (c)  variables  describing 
repair  and  shipping  times  for  the  item,  (d)  variables  describing  the  demand  history 
for  the  item,  (e)  forecast  variables  which  quantify  forecast  usage  rates  and  demand 
variability  and  (f)  control  levels  used  in  the  management  of  the  item's  inventories. 


TABLE  D-6 


Data  Element 
N 

NNEED 

NJOB 


Work-In-Process  File 


Definition 


The  Stock- Keeping-Unit  number  of  the  LRU  that  is  waiting 
for  parts 

The  total  number  of  SRU  components  that  are  required  before 
repair  of  the  LRU  can  be  commenced.  For  example,  if  the 
LRU  requires  three  units  of  SRU#4  and  one  unit  of  SRU06, 
then  NNEED  =  3+1  =  4. 

The  job  number  associated  with  this  reparahle  generation 

The  simulated  clock  time  that  is  entry  was  placed  in  the 
Wait- for- Parts  File 


ITIME 


TABLE  H-7 
Item  Data  File 


Item  Characteristics 


Variable 


Definition 


N 

NITEM 

ALC 

FSN 


UM 

NOUN 

MGTCD 


ISEQ(N) 

UCOST(N) 

LTADM(N) 


LTPROD(N) 


Item  Index 

Number  of  items  simulated 

Air  Logistics  Center  that  manages  this  item 

Federal  Stock  Number,  where 

FSN  (1)  =  Material  Management  Code 
FSN(2)  =  Federal  Stock  Class 
FSN(3)  =  First  six  characters  of  N1IN 
FSN(4)  =  Remaining  characters  of  NIIN 

Unit  of  measure 
Item  name 

Item  Management  Codes,  where 

MGTCD(l)  =  Essentiality  code 
MGTCD(2)  =  Supply  management  grouping 
MGTCD(3)  =  Weapon  system  code 
MGTCD(4)  =  Type  computation  code 

Sequence  number  for  SKU  N 
Unit  cost  (dollars) 

Administrative  lead  time  (days).  Time  required  to  process  and 
transmit  a  requisition  from  a  stocking  location  to  the  resupply 
location. 

Production  Lead  time  (days).  Time  required  to  manufacture 
Of  applicable),  package,  and  transport  a  resupply  order  for 
delivery  of  stock  keeping  unit  N.  This  time  does  not  include 
time  spent  waiting  for  parts.  If  N  is  a  base  level  stock  keeping 
unit,  LTPROD(N)  denotes  the  depot- to-base  ship  time. 


Item  Stock  Status 


INWIP(N) 

INVACT(N) 

IVDUE(N) 

NBOIU(N) 

NBOIR(N) 

NBOTU(N) 

NORDPT(N)* 

NBOPT(N)* 

♦Note 


Units  in  repair  cycle  (work- in- process) 

Actual  serviceable  inventory  on  hand  (units) 

Inventory  due-in  from  supplier  (units) 

Priority  I  backorders,  in  units 
Priority  I  requisitions  backordered 
Total  backorders,  all  priorities,  in  units 

Pointer  to  most  recent  outstanding  order  (Notes  This  variable 
is  not  used  or  updated  in  the  current  RIME  model) 

Pointer  to  oldest,  highest  priority  backorder 


By  convention,  pointers  are  set  to  zero  If  there  are  no  other  elements  in  the  data 
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TABLE  n-7  (Cont'd) 


Reparable  Item  Data 

Variable  Definition 


IBDTT(N) 

IBRT(N) 

IDRT(N) 

IDORT(N) 


Time  to  ship  from  base  to  depot  (days) 
Base  Repair  Time  (days) 

Depot  Repair  Time  (days) 

Depot  Overhaul  Repair  Time  (days) 


History  Variables 


NDHIS 

NDENT(N)* 

NDEMAC(N)* 

NDEMND(N,1)* 

NREQAC(N)* 

NREQ(N,I)* 


Number  of  periods  saved  in  history  file 

Number  of  forecast  periods  sinoe  item  N  enetered  system 
(negative  values  indicate  item  has  not  yet  entered  system) 
Counter  to  accumulate  demand  for  Nth  item  during  the 
current  forecast  update  period. 

Demand  for  item  N  during  Ith  past  period,  1=1,  2,...,NDHIS 
Counter  to  accumulate  the  number  of  requisitions  for  item  N 
during  the  current  period. 

Number  of  requisitions  for  item  N  during  Ith  past  period. 


Forecast  Variables 


ADR(N)* 

RMEAN(N)* 

RTREND(N)* 

RMAD(N)* 

PERSUM(N)* 

KNT(N)* 

RSIGLT(N)* 

REQSIZ(N)* 

REQMAIXN)* 


Net  annual  demand  rate  for  item  N;  the  rate  of  unit  demands 
less  serviceable  returns. 

Estimate  of  mean  demand  rate  during  next  demand  period. 
Estimate  of  trend  in  demand  per  period. 

Mean  Absolute  Deviation  of  unit  demand  per  period. 

Sum  of  past  forecast  errors. 

Counter  used  for  adaptive  smoothing  forecasts. 

Estimate  of  standard  deviation  of  lead  time  demand. 

Estimate  of  mean  requisition  size  for  item  N. 

Mean  absolute  deviation  of  requisition  size  for  item  N. 


Control  Levels 


IROL(N) 

IRQTY(N) 

ISUL(N) 

IRL(N) 

ITL(N) 


Reorder  level  for  item  N 
Reorder  quantity 
Support  level 
Retention  level 
Termination  level 


Notes 

♦These  variable  are  not  used  in  the  current  implementation  of  RIME.  However, 
these  variable  names  are  reserved  for  future  extensions  of  the  model. 
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In  the  current  implementation  of  RIME,  forecast  and  levels  computation 
events  are  treated  as  exogenous  variables,  and  ail  forecasting  and  stock  level 
calculations  are  performed  in  the  Levels  Computation  module  as  a  preprocessing 
step.  Consequently,  the  History  and  Forecast  Variables  defined  in  Table  D-7  are 
neither  used  nor  updated  in  the  current  RIME  model.  However,  these  data  names 
are  reserved  for  future  use  in  studies  in  which  these  activities  are  to  be  treated  as 
endogenous  events. 

Stock  Level  File 

As  noted  in  the  previous  paragraph,  stock  levels  computations  are  performed 
as  a  pre-processing  step  in  the  Levels  Computation  module.  These  pre-computed 
levels  are  recorded  in  the  Stock  Levels  File.  When  a  Levels  Computation  Event 
(Event  Code  6)  occurs  in  RIME,  subroutine  LEVEL  reads  the  Stock  Levels  File  to 
determine  the  required  stock  levels  for  each  Stock  Keeping  Unit.  See  Chapter  IV, 
The  Levels  Computation  System",  for  a  discussion  of  the  data  elements  in  this 
file. 

Backorder  Files 

The  backorder  file  records  all  outstanding  backorders  in  the  inventory  system 
at  a  given  point  in  tune.  This  file  contains  a  record  for  each  requisition  in  a 
backorder  static.  Specific  data  elements  in  this  file  are  defined  in  Table  II-S. 
Included  in  these  data  elements  are  the  SKU  nimber  associated  with  the  backorder, 
the  backorder  quantity  and  priority,  and  the  time  the  item  was  backordered.  A 
pointer  system  is  used  to  relate  entries  in  the  backorder  file  with  the  specific 
stock- keeping- units  associated  with  that  backorder.  These  pointer  variables  are 
also  defined  in  Table  n-S. 
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Variable  Name 
J 

ITMBAC(J) 

IDFSNB(J) 


IPRIOR(3) 

IQTYB(J) 

IBACPT(J) 

NBMAX* 

ILOCBK(K)* 

NLOCBK* 

NOTES 

♦NBMAX,  ILOCBK, 
are  placed  in  this 
subroutine  FILLBO, 


TABLE  n-a 
Backorder  File 


Definition 


File  Index 

simulated  dock  time  that  the  Jth  entry  in  the  backorder  file 
was  placed  into  the  file 

item  number  associated  with  the  Jth  backorder.  If 
IDFSNB(3)=3,  the  backorder  is  for  an  independent  demand 
item.  Otherwise,  if  IDFSNB(J)  is  less  than  1000,  the  backorder 
originated  from  stock- keeping  unit  IDFSNB(3).  If  IDFSNB(J)  is 
greater  than  1000,  the  backorder  is  a  parts  requirement  for 
the  repair  of  LRU  reparable  generation  IDFSNB(J). 

priority  of  Jth  backorder 

quantity  backordered 

pointer  to  the  file  entry  of  the  next  backorder  for  this  same 
item.  If  IBACPT(J)  a  0,  there  are  no  more  backorders  in  the 
list  for  this  SKU. 

maximum  number  of  entries  in  backorder  file 
index  of  Kth  unused  data  location  in  backorder  file 
number  of  unused  data  locations. 


and  NLOCBK  are  initialized  by  subroutine  INITAL.  Backorders 
file  by  subroutine  ENTERB,  and  removed  from  the  file  by 


I 
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Performance  Statistics  File 


The  Performance  Statistics  File  contains  measures  of  the  levels  of  activity 
observed  during  a  simulation  run.  Table  n -9  defines  the  specific  data  elements 
contained  in  this  file.  As  illustrated  in  the  Table,  each  performance  measire  has 
three  different  indexes,  denoted  by  the  variables  I,  J,  and  K.  The  variable  I 
denotes  a  period  index  and  represents  quarter  the  during  the  simulation  in  which 
the  statistic  was  observed.  The  variable  3  denotes  the  unit  of  measurement 
associated  with  the  statistic.  Values  of  3  are: 

1  =  a  count  of  actions  for  Federal  Stock  Numbers  affected. 

2  =  the  total  number  of  units  affected. 

3  =  the  dollar  associated  with  all  of  these  units 


Finally,  the  variable  K  denotes  an  aggregation  category.  Specific  values  utilized  in 
RIME  are  as  follows: 


LRU  at  a  Base. 

SRU  at  a  Base. 

LRU  at  the  Depot. 

SRU  at  the  Depot. 

LRU  at  the  Aircraft  Overhaul  Facility. 
SRU  at  the  Aircraft  Overhaul  Facility. 


For  example,  suppose  that  the  reparable  generation  of  two  units  of  an  SRU  occurs 
at  Base  #3  during  the  eighth  quarter  of  the  simulation.  To  reflect  this  event,  we 
must  update  the  Performance  Statistic  IREPGN  (I,  3,  K).  Sinoe  the  rep  gen  occurs 
in  quarter  8,  the  period  index  is  I  =  8.  Also,  since  we  are  dealing  with  an  SRU  at 
base  level,  the  aggregation  index  is  K  =  2.  Since  we  observed  a  single  reparable 
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TABLE  n-9 

Performance  Statistics  File 


Variable 


Definition 


I 


Period  index,  where  1=  1,  2, 16 


3 


K 


1  =  actions/FSN 

Type  of  measire,  where  3  =  -  2  =  units 

3  =  dollars 


Aggregation  cateogry,  where  K 


1  =  LRU  at  Base 

2  *  SRU  at  Base 

3  =  LRU  at  Depot 

4  =  SRU  at  Depot 

5  =  SRU  at  Overhaul 

Facility 

6  =  SRU  at  Overhaul 

Facility 


1. 

INVOH  (I,  3,  K) 

inventory  on  hand  at  end  of  period 

2. 

INVOR  (I,  3,  K) 

inventory  on-order  at  end  of  period 

3. 

IRECET  (I,  3,  K) 

receipts 

4. 

IRETRN  (I,  3,  K) 

ret  ir  ns 

5. 

INVDAY  (I,  3,  K) 

inventory- weeks 

6. 

IORDER  (I,  3,  K) 

orders  placed 

7. 

IDISPS  (I,  3,  K)* 

disposals 

8. 

ITERM  (I,  3,  K)* 

terminations  completed 

9. 

IEXPED  (I,  3,  K)* 

expediting  actions 

10. 

IRATON  (I,  3,  K)* 

rationing  actions 

11. 

IREQC  (I,  3,  K)* 

total  requisitions  cancelled 

12. 

n>EQT(I,  3,  K) 

total  requisitions  received  from  customers 

13. 

IREQI  (I,  3,  K) 

priority  I  requisitions  received  from  customers 

14. 

IBACKT  (I,  3,  K) 

total  backorders  (end  of  period) 

t 


L 


Note:  *These  variables  are  not  used  in  the  current  version  of  RIME, 
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Variable 

15.  IBACKI  (I,  3,  K) 

16.  1BAKDT  (I,  3,  K) 


17.  IBAKDI  (4  3,  K) 
1BODAT  (4  3,  K) 
IBODAI  (1,  3,  K) 

18.  DFILLT  (I,  3,  K) 

19.  IFILLI  (4  3,  K) 

20.  ISHIPT(4  3fK) 

21.  ISHIPI  (4  3,  K) 

22.  ISMORD  (4  3,  K)* 


23.  ILGORD  (I,  3,  K)* 

24.  IBOPOH  (3) 

25.  IBOPOR  (3) 

26.  IBOPBO  (3) 


TABLE  n-9  (Cont*d) 


Definition 

priority  I  backorders  (end  of  period) 

total  backorder  weeks  within  period 

(Note:  3s  1  denotes  requisition  weeks  of  backorders 

See  SSTAT) 

priority  I  backorder  weeks  within  period  (Note:  3=1 
denotes  requisition  weele  of  backorders  See  SSTAT) 

total  time  on  backorder  for  backorders  filled 
in  period  I  (time  is  in  TUs,  where  100  TUs  =  1  day) 

total  time  on  backorder  for  Priority  1  backorders 
filled  in  period  I  (time  is  in  TUs) 

total  fills  (number  of  requisitions  filled  immediately 
upon  receipt) 

priority  1  fills 

total  shipments 

total  priority  1  shipments 

total  small  orders  (i.e.f  dollar  value  of  order  is  less 
than  a  critical  value  specified  as  input. 

total  large  orders 

on  hand  inventory  at  beginning  of  simulation 
on-order  inventory  at  beginning  of  simulation 
backorders  at  beginning  of  simulation 


reparable  generations  at  this  location  (for  depot, 
NRTS  items  are  not  inlcuded.) 

number  of  units  not  reparable  at  this  station 
(NRTS).  For  a  base,  these  are  NRTS  units  sent  to  the 
depot.  For  depot  locations  (i.e.,  for  K=3  or  4)  this 
variable  represents  NRTS  assets  routed  to  the  depot. 


2. 


INRTS  (I,  3,  K) 


Repair  SWlstlcs 


TABLE  n-9  (Cont'd) 


3.  ICNDEM  (I,  3,  K) 

4. 

5. 


number  of  reparable  generations  condemned  this 
period.  Note:  Number  of  NRTS  items  =  IREPGN-IRTS 
ICONDM 

number  of  repairs  completed 

Work  in  process  at  end  of  period 

Time  waiting  for  parts  -  (in  TUs,  100  TUs  = 

1  day)  (Computed  by  RCVPRT  when  parts  are  finally 
received,  in  the  quarter  received.) 


6. 


IRECPL  (I,  3,  K) 
IWIP  (I,  3,  K) 
1WFP  (I,  3,  K) 


generation,  the  action  count  (3  =  1)  statistic  IREPGN  (8,  1,  2)  is  increased  by  1 
even  though  two  assets  were  involved.  However,  since  two  assets  generated  at  this 
time,  the  units  count  (3  =  2)  statistic  is  increased  from  IREPGN  (8,  2,  2)  to  a  value 
of  IREPGEN  (8,  2,  2)  ♦  2.  Finally,  suppose  that  the  LRU  has  a  unit  price  of  $6,500. 
In  this  case,  the  dollars  (3=3)  statistic  IREPGN  (8,  3,  2)  is  increased  by  2  x  $6,5000 
=  $13,000.  The  subroutine  CUM  is  used  to  perform  these  update  calculations  for  all 
of  the  Performance  Statistics  shown  in  Table  II >8. 

Simulation  Counters  and  Flags 

Every  simulation  model  requires  a  series  of  counters  and  flags  to  control  the 
progress  of  the  simulation,  and  to  perform  necessary  bookkeeping  tasks.  The 
number  of  quarters  to  be  simulated,  the  number  of  the  current  statistics  collection 
interval,  and  the  number  of  simulation  runs  to  be  performed  are  examples  of  these 
types  of  data  elements.  The  variables  of  the  Futire  Events  List  are  an  important 
example  of  this  type  of  information.  Other  major  variables  in  this  category  are 
defined  as  inputs  to  RIME  through  File  05.  These  latter  variables  are  discussed  in 


detail  in  Section  VI. 


Chapter  III 


The  Events  Generator 

The  Events  Generator  uses  Monte  Carlo  techniques  to  generate  detailed  lists 
of  LRU  and  SRU  reparable  generations  and  all  related  requisition,  condemnation, 
and  repair  activities.  This  chapter  describes  the  major  features  of  this  system  and 
the  computer  codes  which  implement  it. 

The  Event  Generation  Process 

A  major  design  feat  ire  of  the  RIME  evaluation  model  is  that  all  recoverable 
item  flows  are  driven  by  actual  Air  Force  histories  of  recoverable  item  activity. 
For  example,  Table  III- 1  presents  historical  data  from  the  D041  Depot  Data  Bank 
for  Federal  Stock  Nunber  5841-00-2475357.  This  FSN  is  a  Line  Replaceable  Unit 
for  the  F-lll  aircraft  with  a  price  of  $6,150  per  unit.  This  LRU  has  a  single  SRU 
component;  the  SRU  is  FSN  5841-00-4899835,  a  SYNC  ASSY  with  a  unit  price  of 
$452.20.  Table  III-l  presents  the  repairable  item  generation  data  for  these  two 
stock  numbers  for  the  first  quarter  of  FY74,  as  well  as  the  total  repairable 
generation  in  each  category  shown  for  the  four  year  period  from  FY74-1  through 
FY78  -4. 

As  shown  in  the  table,  this  LRU  had  115  repairable  generations  during  the  first 
quarter  of  FY74.  Of  this  total,  110  were  repaired  at  base  level,  while  5  were  NRTS 
assets.  That  is,  five  assets  were  retimed  to  the  depot  for  repair.  None  of  the 
total  of  115  assets  were  condemned  at  the  base  level,  and  there  were  no  depot 
repairable  generations  of  this  LRU  during  FY74-1  (i .e*  there  were  no  generations 
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*  The  total  number  of  assets  which  completed  repair  in  a  given  quarter  is  available  from  the  D041  Depot  Data  Bank. 
However,  this  information  is  not  used  in  RIME,  since  these  numbers  reflect  the  performance  of  past  inventory 
management  policies,  and  that  are  not  necessarily  representative  of  the  inventory  management  rules  to  be  evaluated. 
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Table  Xll-1  (cont.) 
SAMPI^  HISTORICAL  TiATA 


FSN 

*8410024753*7 


NOUN  1  Rim 

GYNwHR0134  6 1 5 0 .0  0 


1 

2 

3 

4 

BRGb 

115 

131 

102 

103 

RTS 

110 

131 

102 

101 

BCBN 

0 

0 

0 

0 

NRTS 

* 

0 

0 

2 

drgn 

0 

0 

0 

0 

GCNG 

0 

0 

0 

0 

GRfcP 

* 

4 

0 

0 

OVCN 

0 

0 

0 

0 

PHOG 

duo 

278 

270  ‘ 

314 

9 

10 

11 

12 

13* 

177 

14b 

111 

lib 

176 

146 

109 

u 

0 

U 

0 

u 

1 

2 

2 

u 

0 

U 

6 

u 

0 

u 

0 

0 

10 

* 

* 

0 

0 

u 

0 

.  236  • 

2*8 

30  J 

?66 

5 

6 

l 

8 

ll6" 

ITT 

m 

14* 

120 

109 

134 

137 

0 

0 

0 

0 

6 

2 

4 

8 

U 

0 

0 

0 

0 

0 

0 

0 

1 

1 

1 

6 

0 

0 

0 

0 

304 

2*2 

28b 

230 

13 

14 

15 

16 

Total 

To7 

nr 

~ffT 

TT?** 

1980 

107 

132 

8* 

Ill** 

194* 

0 

0 

u 

u«  * 

0 

0 

2 

0 

i«» 

3* 

0 

0 

V 

o«* 
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0 

0«* 
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1 

2 

1 

2-* 

50 
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289 
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2b2«» 
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*84100489985* 
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ASSY 
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2 

3 
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TT 

TT 

2 

RTS 

2 

2 

0 

BCON 

0 

0 

0 

KRTS 

8 

1? 

2 

ORGN 

0 

u 

0 

1)Cnu 

n 

0 

u 

DRl  P 

10 

l 

6 

OVCn 

0 

0 

0 

PROG 

3o0 

27a 

270 

9 

8 

22. 
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11 

Tb 

2 
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1 
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i 
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6 

?• 

1* 

0 

ii 
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0 

it 

0 

* 

<• 
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t 

u 
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2*t 
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a  SRU 


4  5 

12  8 

6 

7 

7 

13 

8 

* 

0 

1 

2 

0 

0 

8 

0 

0 

0 

0 

12 

7 

5 

13 

6 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

10 

7 

3 

7 

9 

0 

0 

0 

0 

0 

304 

304 

2*2 

288 

230 

12 

13 

14 

15 

16 

Total 

8 

6 

3 

“T 

T  *  •  • 

"TO 

0 

0 

0 

0 

0«» 

10 

0 

0 

0 

0 

0** 

1 

8 

6 

3 

1 

*•• 

113 

2 

0 

0 

0 

0«« 

2 

0 

0 

0 

0 

u  •  * 

0 

7 

/  u 

7 

2 

3«* 

10a 

0 

0 

0 

0 

0*« 

0 

2*6 

289 

2*9 

189 

202«* 

4246 

nx-4 


from  the  Overbad  Facility).  During  this  quarter,  the  LRU  had  a  total  installed 
program  of  30,000  hours.  Similarly,  the  SRU  had  10  repairable  generations  during 
this  quarter.  Two  of  these  were  repaired  at  base  level,  while  8  were  returned  to 
the  depot. 

In  simulating  this  LRU/SRU  family  for  the  quarter  FY74-1,  exactly  115 
repairable  generations  of  the  LRU  are  created  in  the  RIME  model,  with  exactly  110 
of  these  to  be  repaired  at  base  level.  Similarly,  exactly  10  SRU  repairable 
generations  are  created  in  the  simdation  of  this  quarter,  with  2  repaired  at  base 
level  and  8  returned  to  the  depot.  In  a  simdation  of  the  entire  FY74-1  through 
FY78-4  interval,  exactly  1980  LRU  generations  wodd  be  created,  and  exactly  124 
SRU  generations.  Similarly,  all  of  the  other  historical  data  displayed  in  Table  III- 1 
wodd  be  exactly  reproduced  by  the  simdation  model. 

One  problem  in  simdating  detailed  repairable  item  flows  from  Air  Force 
historical  data  is  that  the  historical  data  is  maintained  in  an  aggregated  form. 
That  is,  the  historical  records  only  tell  us  the  total  number  of  repairable 
generations  that  occurred  at  all  base  locations  during  a  given  interval,  and  provides 
no  information  in  terms  of  which  specific  bases  generated  these  failures.  Simi¬ 
larly,  the  historical  records  provide  no  data  which  allow  us  to  link  up  specific  SRU 
repairable  generations  with  associated  LRu  failures.  Consequently,  it  was  neces¬ 
sary  to  devise  probability  models  to  interrelate  LRU  and  SRU  reparable  general 
tions.  Table  III-2  presents  the  assumptions  utilized  in  our  demand  generation 
process.  Basically,  the  rdes  presented  in  this  table  are  based  on  a  relatively  small 
nunber  of  fundamental  assumptions.  These  are  (a)  Air  Force  D041  recoverable 
item  flow  histories  are  to  be  reproduced  as  dosely  as  possible  in  the  simulation 
process,  (b)  the  probability  that  a  specific  SRU  failure  in  a  given  quarter  is  related 


Table  HI-2 

Basic  Assunptions  of  RIME  Reparable  Generation  Probability  Model 


I.  Base  Reparable  Generations 

1.  The  probability  that  a  specific  LRU  reparable  generation  occurs  at  a 
given  location  is  proportional  to  the  flying  activity  at  that  location  relative  to  the 
total  flying  activity  at  all  locations  in  the  specific  quarter  under  consideration. 
Further,  it  is  assuned  that  a  uniform  distribution  describes  the  probability  that  a 
given  LRU  rep  gen  occurs  at  any  specific  instance  within  the  quarter  under 
consideration.  This  is  equivalent  to  assuming  that  LRU  reparable  generations 
follow  a  simple  Poisson  process  within  the  specific  quarter  of  interest.  However, 
the  exact  number  of  LRU  reparable  generations  within  a  given  quarter  exactly 
equals  the  historical  values  recorded  in  D041. 

2.  The  probability  that  a  given  SRU  rep  gen  (RTS,  NRTS,  or  condemnation)  is 
related  to  a  given  LRU  rep  gen  is  equal  to  the  ratio  of  the  total  SRU  rep  gens  in  a 
given  quarter  to  the  total  number  of  SRUs  installed  in  LRUs  that  fail  during  that 
quarter.  We  refer  to  this  as  the  Exposure  Probability  model.  Once  an  SRU  rep  gen 
is  related  to  a  specific  LRU  rep  gen,  the  dock  times  for  related  SRU  events  are 
determined  by  addng  appropriate  time  delays  to  the  LRU  failure  time. 

3.  If  recorded  D041  LRU  rep  gens  exceed  recorded  D041  SRU  rep  gens,  it  is 
assuned  that  some  LRUs  were  repaired  without  requiring  replacement  SRUs. 
Calibration  and  adjustment  actions  and  job-routed  repairs  are  examples  of  this 
situation. 


4.  If  recorded  D041  SRU  rep  gens  exceed  the  total  SRUs  installed  in  failing 
LRUs,  we  assune  the  excess  units  are  "independent  SRU  demands";  that  is, 
demands  that  are  independent  of  an  associated  LRU  turn-in  to  base  supply.  This 
situation  will  occur  if  an  LRU  is  repaired  at  the  flight  line,  rather  that  in  the  base 
maintenance  shops. 

3.  If  an  LRU  is  condemned,  all  SRUs  in  the  condemned  LRU  that  are  not 
reparable  or  condemned  are  treated  as  serviceable  returns  to  the  supply  system. 

II.  Depot  Reparable  Generations 

1.  LRU  depot  delays  are  simulated  ising  the  same  assumptions  employed  in 
the  METRIC  and  MOD- METRIC  models;  namely,  LRU  depot  delays  are  treated  as 
independent  random  variables,  independent  of  SRU  stock  status  at  the  depot. 
Hence,  although  the  LRU  repair  time  may  indude  an  allowance  for  parts  delays, 
these  delays  are  not  expliatly  simulated. 

2.  Since  all  LRU  depot  delays  are  treated  as  independent  random  variables, 
all  SRU  depot  reparable  generations  are  also  treated  as  "independent";  that  is, 
these  generations  are  not  related  to  any  of  the  LRU  generations. 
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3.  It  is  assumed  that  the  specific  time  that  a  given  LRU  or  SRU  depot 
reparable  generation  occurs  is  uniformly  distributed  over  the  specific  quarter  under 
consideration.  This  is  equivalent  to  assuming  that  both  LRU  and  SRU  depot  rep 
gens  obey  simple  Poisson  processes. 

HI.  Forecasting  Assumptions 

1.  All  values  for  Mean  Time  Between  Demands  (MTBD),  NRTS  rates,  and 
condemnation  rates  are  based  upon  eight-quarter  moving  averages  of  past  repar¬ 
able  generation  activity.  However,  at  least  four  quarters  of  data  are  always  used 
for  these  estimates.  Hence,  to  estimate  these  values  at  the  beginning  of  FY74- 1 
we  use  the  D041  data  for  quarters  FY74-1  through  FY74-4,  since  no  data  prior  to 
FY74-1  is  available.  To  estimate  rates  to  be  used  in  simulating  FY77-L,  however, 
we  use  the  D041  data  for  the  eight  quarters  between  FY75-1  and  FY76-4.  This 
interval  represents  the  most  recent  eight- quarters  of  historical  data  that  would  be 
available  at  the  start  of  FY77- 1. 

2.  For  operating  bases,  forecasts  for  future  rep  gens  are  based  upon 
historical  failure  rates  and  the  actual  D041  program  activity  for  the  future  period. 
Specific  LRU  installed  programs  by  base  are  determined  by  allocating  the  total 
LRU  program  in  proportion  to  the  aircraft  base  programs  shown  in  Figures  III- 1  and 
III- 2,  as  appropriate.  For  forecasts  of  Aircraft  Overhaul  requirements,  it  is 
assumed  that  the  expected  depot  rep  gen  rate  may  be  forecast  perfectly  over  a  one 
year  time  horizon;  however,  it  is  further  assumed  that  errors  occur  in  forecasting 
the  precise  time  within  the  year  that  these  depot  rep  gens  occur. 

3.  All  depot  reparable  generations  are  assumed  to  originate  from  a  single 
aircraft  overhaul  facility.  Stock  levels  for  this  facility  are  computed  to  provide  a 
14-day  supply. 


to  a  given  LRU  repairable  generation  is  assimed  proportional  to  the  total  nunber 
of  SRU  units  that  are  contained  in  the  assemblies  of  the  failed  LRUs.  For 
example,  for  the  LRU/SRU  pair  presented  in  Table  111-1,  there  are  two  units  of  the 
SRU  contained  in  each  LRU;  that  is,  the  Quantity  Per  Application  (QPA)  for  the 
SRU  is  two.  Consequently,  for  the  110  LRUs  that  were  repaired  in  the  liO  LRU 
repairable  generations.  Further,  since  there  were  exactly  10  repairable  genera¬ 
tions  for  the  SRU  during  this  period,  we  assime  that  the  probability  that  any 
specific  SRU  component  wasfaiityis  10/220. 

In  analyzing  Air  Force  historical  records,  we  were  unahle  to  relate  condmena- 
tion  actions  recorded  in  one  period  to  specific  repairable  generation  actions 
reoorded  in  other  periods.  Consequently,  in  simiiating  both  depot  condemned  and 
depot  overhaii  condemned  actions,  we  use  a  probability  model  which  guarantees 
that  the  total  rxxnber  of  condemnations  over  the  four  year  simulation  period 
exactly  equals  the  rnmber  of  condemnations  recorded  in  Air  Force  repairable 
generation  histories.  However,  we  do  not  attempt  to  reproduce  the  specific 
quarter- by- quarter  condemnation  quantities  which  are  recorded  in  the  D041  Depot 
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Relationships  Among  Exogenous  Events 

As  noted  above,  the  objective  of  the  Events  Generator  is  to  generate  detailed 
descriptions  of  each  LRU  and  SRU  reparable  generation  in  such  a  way  that  the 
totals  of  these  events  exactly  equal  values  recorded  in  D041  reparable  generation 
histories.  In  doing  this,  we  wish  to  generate  not  only  events  describing  specific 
reparable  generations,  but  also  to  generate  all  associated  serviceable  return, 
repair,  NRTS,  and  condemnation  actions  whose  timing  may  be  determined  from  the 
timing  of  the  reparable  generation  event.  Table  III- 1  presents  a  sample  of 
historical  reparable  generation  data  which  drives  the  Events  Generator,  while 
Table  II1-2  defines  the  probability  model  used  to  generate  specific  reparable 
generation  events.  On  the  other  hand,  Figures  ID-1  through  III -4  describe  the 
relationships  between  reparable  generation  events  and  all  associated  exogenous 
events  "caused  by"  the  reparable  generation. 

Figure  III- 1  illustrates  the  relationships  among  exogenous  events  caused  by  an 
LRU  base  reparable  generation.  As  shown  in  the  figure,  an  LRU  base  rep  gen  event 
is  always  accompanied  by  a  corresponding  requisition  (Event  Type  1)  for  a 
replacement  (serviceable)  LRU.  In  addition,  one  of  three  possible  additional  LRU 
events  may  be  related  to  the  LRU  base  rep  gen.  These  are:  (a)  an  LRU  base 
condemnation  event  (Event  Type  15),  (b)  an  LRU  RTS  event  (Event  Type  18),  or  (c) 
an  LRU  NRTS  event  (Event  Type  19).  Which  of  these  three  specific  events  will  be 
generated  depends  on  a  Monte  Carlo  computation  to  be  discussed  later  in  this 
section.  Suppose  that  this  Monte  Carlo  jlculation  indicates  that  the  LRU  base 
reparable  generation  is  to  be  condemned.  As  shown  in  Figure  in- 1,  the  next  step  is 
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to  determine  the  relationships  between  the  condemned  LRU  asset  and  the 
individual  SRU  components  which  go  into  the  LRU  unit.  As  shown  in  the  Figure,  a 
Monte  Carlo  process  is  applied  to  determine  the  status  of  each  SRU  unit  that  is  a 
member  of  the  condemned  LRU  asset.  If  the  Monte  Carlo  computation  indicates 
that  the  SRU  is  serviceable,  the  Event  Generator  schedules  a  Serviceable  Return 
event  (Event  Type  4)  to  represent  the  return  of  the  serviceable  SRU  to  available 
base  stocks.  On  the  other  hand,  the  Monte  Carlo  computation  may  indicate  that 
the  SRU  component  is  in  some  way  faulty.  In  this  case,  the  Events  Generator 
schedules  a  Base  Reparable  Generation  event  (Event  Type  14)  for  each  faulty  SRU 
component.  Monte  Carlo  techniques  are  also  ised  to  determine  the  additional 
exogenous  events  to  associate  with  the  SRU  reparable  generation.  As  shown  in 
Figure  in- 1,  one  of  three  different  exogenous  events  may  be  associated  with  a 
given  SRU  Base  Reparable  Generation  event.  These  are;  (a)  completion  of  repair 
activities  for  the  SRU  (Event  Type  18),  (b)  condemnation  of  the  SRU  (Event  Type 
15),  or  (c)  Initiation  of  a  NRTS  event  (Event  Type  19)  to  represent  the  beginning  of 
transportation  of  the  faulty  SRU  to  the  depot  level  repair  facility.  In  the  latter 
case,  i.e.,  the  case  of  an  SRU  NRTS  event,  a  Monte  Carlo  process  is  again  used  to 
determine  the  disposition  of  the  SRU  when  it  reaches  the  Depot  Level  Maintenance 
facility.  One  possibility  is  that  the  SRU  may  be  successfully  repaired  at  the  depot 
level.  In  this  case,  the  Events  Generator  schedules  an  SRU  repair  completion  event 
(Event  Type  18)  to  occur  at  the  depot.  The  other  possibility  is  that  the  SRU  cannot 
be  repaired.  In  this  case,  the  Events  Generator  schedules  a  Condemnation  event 
(Event  Type  15)  to  occur  for  the  SRU  after  a  suitable  time  delay  to  represent  the 
time  required  to  transport  the  SRU  to  the  depot. 
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Figure  III-2  iliictrates  the  logic  for  generating  exogenous  events  associated 
with  an  LRU  rep  gen  that  is  repaired  at  base  level.  As  shown  in  the  figure,  one 
possibility  is  that  the  failed  LRU  may  be  repaired  without  the  replacement  of  any 
of  its  SRU  components.  In  this  case,  the  Events  Generator  schedules  a  repair 
completion  event  (Event  Type  IS)  for  the  LRU  to  occur  after  an  appropriate  repair 
time  delay.  On  the  other  hand,  repair  of  the  LRU  may  reqiire  the  removal  and 
replacement  of  at  least  one  of  its  SRU  components.  In  the  latter  case,  the  Events 
Generator  first  schedules  a  "Begin  Waif  event  (Event  Type  16)  for  the  LRU, 
indicating  that  repair  of  LRU  cannot  proceed  until  stitable  SRU  replacements  are 
available.  As  shown  in  Figure  ID-2,  the  Begin  Wait  event  is  also  accompanied  by 
the  generation  of  exogenous  events  representing  requisitions  of  all  needed  SRU 
components.  Once  all  of  the  serviceable  SRU  units  reqiired  for  the  repair  of  the 
LRU  are  received,  the  LRU  is  removed  from  the  Wait- for- Parts  static,  and  a 
Repair  Completion  event  for  the  LRU  may  be  scheduled.  These  latter  activities 
removing  the  LRU  from  its  wait  static  and  scheduling  repair  completion  are 
performed  by  subroutine  RCVPRT  within  the  RIME  Simulation  Model,  and  are  not 
part  of  the  Events  Generator. 

As  shown  in  in  Figure  III-2,  several  SRU  base  reparable  generation  events  may 
also  be  scheduled  for  each  f  aiity  SRU  contained  in  the  LRU  rep  gen.  In  this  event, 
a  Monte  Carlo  process  is  used  to  determine  if  a  specific  SRU  base  rep  gen  is  to  be 
(a)  repaired  at  base  level  (Event  Type  1 S),  (b)  condemned  at  the  base  (Event  Type 
15),  or  (c)  shipped  to  the  depot  for  additional  repair  operations  (Event  Type  19).  In 
the  latter  case,  Monte  Carlo  calculations  are  also  iced  to  determine  if  the  SRU  is 
to  be  repaired  at  the  depot  or  if  it  is  to  be  condemned. 


\  Figure  III-2.  Events  Caused  by  an  LRU  RTS  Event 
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As  shown  in  Table  I1I-2,  we  attempt  to  relate  all  SRU  base  reparable 
generations  to  LRU  reparable  generations.  However,  this  is  not  always  possible. 
At  times,  D041  histories  show  more  SRU  base  reparable  generations  then  can  be 
explained  by  the  failure  of  every  SRU  installed  in  all  recorded  LRU  failures.  In 
RIME,  we  assume  that  all  SRU  reparable  generations  which  cannot  be  associated 
with  LRU  failures  are  "independent"  base  reparable  generations.  Such  generations 
might  occir,  for  example,  if  faiity  SRUs  are  removed  from  an  LRU  at  the 
flightline,  rather  than  at  an  intermediate  repair  organization.  In  this  case,  the 
LRU  reparable  generation  would  never  be  recorded  in  the  D041  demand  history, 
while  the  SRU  reparable  generation  would  be  recorded. 

Figure  ID-3  illustrates  the  relationships  among  all  exogenous  events  associated 
with  Independent  SRU  base  reparable  generation  events.  As  may  be  seen  in  the 
figure,  these  are  essentially  the  same  event  relationships  as  when  the  SRU  is 
associated  wtihan  LRU  failure. 

Figure  III-4  illustrates  the  relationship  among  exogenous  events  associated 
with  the  Depot  Level  Maintenance  facility.  As  shown  in  the  figure,  there  is  no 
attempt  to  relate  LRU  repair  or  condemnation  actions  at  the  depot  level  with  SRU 
repair  or  condemnation  events.  Basically,  this  flowchart  assumes  the  same 
LRU/SRU  depot  relationships  as  those  modeled  in  the  METRIC  and  MOD-METRIC 
mathematical  models. 
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Figur#  ITI-4. 
Depot  Level  Events 
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Note i  Job~Routed  Depot  Reparable  Generations  are  not  recorded 
in  D041,  and  are  thus  not  simulated  in  RIME. 
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Progams  Used  in  the  Events  Generator 

Figure  III-5  iUustrates  the  computer  programs  which  implement  the  Events 
Generator.  As  shown  in  the  figure,  the  program  EVTGN2  is  the  main  program  for 
the  events  generation  process.  The  subroutines  BASEDA  and  READF2  are  used  to 
input  base  flying  program  data  by  quarter  and  LRU/SRU  item  data,  respectively. 
The  subroutines  NOSETl  and  NOSET2  are  used  to  set  counters  required  to  control 
the  events  generation  process.  Subroutine  NOSETl  sets  counters  of  depot  level 
events,  while  NOSET2  sets  base  level  counters.  The  routines  LRUEVT  and  SRUEVT 
perform  the  bulk  of  calculations  in  the  Events  Generator.  The  routine  LRUEVT 
controls  the  scheduling  of  LRU  reparable  generations  and  all  associated  LRU 
exogenous  events,  and  LRUEVT  calls  subroutine  SRUEVT  to  generate  all  related 
SRU  events.  In  some  cases,  D041  histories  show  more  SRU  reparable  generations 
than  can  be  explained  by  the  historical  values  for  LRU  reparable  generations.  In 
this  case,  the  subroutine  SRUIND  is  called  to  schedule  all  "excess"  SRU  reparable 
generations  as  "independent?'  events.  In  turn,  SRUIND  calls  subroutine  SCHIND  to 
perform  the  detailed  scheduling  calculations  associated  with  these  independent 
events. 

In  addition,  three  general  utility  routines  —  INFEL,  ENTER,  and  REMOVE  — 
are  called  to  facilitate  the  scheduling  of  exogenous  events.  Subroutine  INFEL  is 
called  to  initialize  the  Futire  Events  List  (FEL),  while  subroutine  ENTER  is  called 
to  place  specific  events  on  the  FEL.  At  the  end  of  each  quarter,  subroutine 
REMOVE  is  called  to  remove  all  events  associated  with  the  given  quarter  from  the 
Future  Events  List.  Let  us  now  consider  interrelationships  among  these  routines  in 


more  detail. 


Figure  in-5. 
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EVTGN2:  The  Exogenous  Event  Generator  Main  Program 

The  program  EVTGN2  is  the  main  program  for  the  Exogenous  Event  Generator. 
A  flow  chart  of  the  major  computations  performed  by  EVTGN2  is  shown  in  Figure 
HI-6,  while  detailed  source  program  listings  of  EVTGN2  are  presented  in  Volume  n. 
As  shown  in  the  figure,  EVTGN2  begins  by  reading  parameters  which  control  the 
computations  performed  by  the  Events  Generator,  and  which  control  the  types  of 
outputs  to  be  produced  during  the  Events  Generation  Process.  The  run  parameters 
read  in  are: 

NFGRP  =  The  number  of  the  first  LRU/SRU  group  included 
in  the  events  generation  process. 

NLGRP  =  The  number  of  the  last  LRU/SRU  group  be  included 
in  the  events  generation  process. 

NBASES  =  The  number  of  operating  bases  assumed  during 
events  generation  process. 

INQTR  =  The  number  of  quarters  in  the  events  generation 
planning  horizon. 


NREPL 


The  number  of  replications  to  be  performed  for  each 
LRU/SRU  group. 
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IWT(I)  =  A  "Write"  Flag,  which  specifies  if 

output  option  I  is  to  be  exercised.  If  IWT(I) 
s  l,  the  Ith  print  option  is  to  be  used; 
otherwise,  that  option  is  not  used. 

The  Write  Flags  are  most  useful  during  the  debugging  of  new  data  sets  and  in 
the  development  of  alternate  versions  of  the  Events  Generation  System.  Table 
111-3  defines  the  specific  meanings  of  each  of  these  Flags. 

After  reading  the  run  parameters  and  Write  Fiags,  subroutine  BASEDA  is 
called  to  read  in  base  order  and  ship  times.  BASEDA  also  reads  in  flying  program 
data  by  base  for  each  quarto-  in  the  events  generation  planning  horizon.  Next, 
EVTGN2  scans  down  the  Master  Data  Set  until  LRU/SRU  group  NFGRP  is  found. 
The  routine  then  begins  the  generation  of  exogenous  events  with  this  particular 
group. 

In  processing  each  new  LRU/SRU  group,  the  replication  counter  KREPL  is 
reset  to  1,  and  the  reparable  generation  counter  NJOB  is  set  to  1,000.  The  Future 
Events  List  is  then  initialized  by  caliing  subroutine  INFEL,  and  the  counters  of 
depot  level  events  are  initialized  by  a  call  to  subroutine  NOSET  1. 

The  quarter  loop  now  begins  by  setting  the  quarter  counter  variable  IQTR  =  1. 
At  the  beginning  of  each  quarter,  subroutine  RANBS1  is  called  to  initialize  the 
base  probability  array  CPROB,  and  subroutine  NOSET2  is  called  to  initialize  the 
counters  of  all  base  level  events  to  be  generated  within  the  current  quarter. 
Probability  array  CPROB  is  used  by  subroutine  RANBAS  later  in  the  events 
generation  process  to  determine  a  randomly  selected  base.  This  selection  is 
performed  so  that  the  base  selection  probability  is  proportional  to  the  flying  hour 
activity  at  each  base  in  specific  quarter  under  consideration. 
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Figure  III-6  (Continued) 


TABLE  m-3 


Write  Flag 


Number 

Routine 

1 

READFL 

2 

READFL 

3 

NOSET  1 
NOSET2 

4 

LRUEV2 

5 

ASSIGN 

6 

SRUEVT 

7 

SCHIND 

8 

EVNTGN2 

9 

EVNTGN2 

10 

ENTER, 

REMOVE 

11 

EVTGN2 

12 

BASE  DA 

13 

RANBS1 

EVENTS  GENERATOR 
WRITE  FLAGS 


Effect 


Print  all  data  read  in,where  (1)  =  print  short  header  only, 
(2)  =  print  header  and  rep  gen  data,  (3)  =  print  all  data 
input 

Print  header  data  written  to  EXOGFILE 
Print  values  for  all  event  counters 


Print  number  of  failed  SRU  components  in  each  LRU 
rep  gen 

Print  details  of  individual  component  Monte  Carlo 
failure  cal  dilations 

Print  details  of  dependent  SRU  events 
generated  by  SRUEVT 

Print  details  of  independent  SRU  event  generation 

Print  values  of  LRU  counters 

Print  events  written  to  File  08 

Print  all  entries  and  removals  to  the  Futire  Events 
List 

Set  IOUT  =  1,  and  produce  a  binary  exogenous  event 
file  on  File  08. 

Write  base  data 

Write  base  probabilities 
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After  the  above  initialization  procedures,  subroutine  LRUEVT  is  called  three 
times  to  generate  all  exogenous  events  associated  with  historical  D041  LRU 
reparable  generations  associated  with  quarter  IQTR.  First,  LRUEVT  is  called  to 
generate  specific  events  associated  with  historical  LRU  base  RTS  and  base 
condemnation  events.  The  second  and  third  calls  to  subroutine  LRUEVT  generate 
all  exogenous  events  associated  with  LRU  NRTS  and  LRU  depot  reparable 
generations,  respectively.  In  performing  the  LRU  event  generation  process, 
subroutine  ASSIGN  is  called  to  determine  the  number  of  SRU  reparable  generations 
to  associate  with  each  LRU  failure,  while  subroutine  SRUEVT  is  called  to  schedule 
the  specific  exogenous  events  associated  with  these  SRU  reparable  generations. 

After  all  LRU  events  have  been  scheduled,  subroutine  SRUIND  is  called.  This 
routine  checks  the  base  level  counter  arrays  for  each  SRU  to  determine  if  there 
are  any  remaining  SRU  reparable  generations,  i.e.,  SRU  generations  which  could 
not  logically  be  associated  with  LRU  failures.  If  so,  subroutine  SCHIND  is  called 
to  schedule  the  remaining  SRU  events  as  "independent”  SRU  reparable  generations, 
and  to  schedule  all  related  requisition,  cancellation,  and  repair  activities. 

Finally,  at  the  end  of  each  simulated  quarter,  subroutine  REMOVE  is  called  to 
remove  all  exogenous  events  scheduled  for  quarter  IQTR  from  the  FEL,  and  to 
output  an  event  record  to  the  Exogenous  Event  File  (File  08).  The  quarter  counter 
IQTR  is  then  increased  by  one,  and  the  event  generation  process  continues  until  all 
quarters  have  been  considered. 

After  all  quarters  have  been  processed,  an  "End-of-Run”  (Event  Type  10) 
event  record  is  written  to  the  Exogenous  Event  File.  The  RIME  Simulation  Model 
uses  the  "End-of-Run”  event  record  to  determine  that  there  are  no  additional 
events  for  the  current  replication  of  a  given  LRU/SRU  group.  If  additional 
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replications  are  required,  program  control  returns  to  the  beginning  of  program 
EVTGN2,  and  a  new  set  of  events  are  generated  using  different  values  for  random 
number  seeds.  The  event  generation  process  is  then  repeated  using  different 
random  values  until  all  replications  have  been  performed.  After  all  required 
replications  are  completed,  EVTGN2  reads  the  next  LRU/SRU  data  set  from  the 
Master  Data  File  Set,  and  the  events  generation  process  is  performed  for  the  new 
LRU/SRU  group.  This  process  continues  until  all  LRU/SRU  groups  from  NFGRP 
through  NLGRP  have  been  processed. 

Variable  Definitions  and  Relationships 

A  large  number  of  variables  are  required  to  keep  track  of  the  number  of 
reparable  generation,  RTS,  NRTS,  and  condemnation  events  remaining  to  be 
generated  for  each  LRU  and  SRU.  The  major  variables  used  to  do  this  are  shown  in 
Table  HI-4.  The  depot  event  counters  are  initialized  by  subroutine  NOSET  1  at  the 
beginning  of  quarter  1  for  each  replication,  while  counters  of  base-level  events 
are  reset  each  quarter  by  subroutine  NOSET2.  Each  of  these  variables  are  then 
decremented  as  the  associated  events  are  scheduled.  Table  III-5  presents  the 
calculation  formulas  used  to  determine  the  probabilities  of  specific  exogenous 
events  used  in  the  Monte  Carlo  calculations,  while  Figure  III- 7  provides  a  graphical 
description  of  the  relationship  among  these  variables.  In  general,  variables  starting 
with  an  "L"  denote  counts  for  the  LRUs,  while  variables  beginning  with  a  "N” 
denote  counts  for  SRUs.  Variables  starting  with  a  "I”  denote  variables  which  are 
provided  as  input  to  the  Events  Generator  through  subroutine  READFL.  Defini¬ 
tions  of  these  latter  input  variables  may  be  found  in  the  record  layouts  section  of 
Volume  II.  Finally,  variables  ending  in  "T"  denote  the  total  number  of  assets 
summed  over  all  periods  in  the  planning  horizon. 
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TABLE  III-4 

EVENTS  GENERATOR 
VARIABLE  DEFINITIONS 

VARIABLE  DEFINITION 

NLRUGP  Number  of  LRU/SRU  groups  to  be  simulated. 

NBASES  Number  of  Operating  Bases. 

NSRU  Number  of  SRUs  in  the  LRU. 

NITEM  Number  of  stock-keeping  units  (SKUs). 

NMPH  Number  of  months  of  program  data  provided. 

INQTR  Number  of  quarters  of  events  to  be  generated. 

FH(I,3)  Flying  program  (in  100s  of  hours)  in  quarter  I  at  base  3. 

TFH(J)  Total  flying  program  at  base  3  for  months  1,  2,....,NMPH. 

ITINV  Current  Quarter  index. 

ITDAY  Time  units  in  1  day  (ITDAY  =  100  Time  Units). 

ITQTR  Time  units  in  1  quarter  =  8400  (7  days/week  x  4  weeks/month  x  3 

months/quarter). 

For  a  given  quarter,  let  K  denote  the  Kth  type  of  SRU  in  an  LRU.  Then. 

NOINL(K)  Number  of  SRU  Type  K  failures  in  the  LRU  reparable  generation 
currently  being  considered. 

NOSRUF(K)  Total  number  of  base  level  RTS,  NRTS,  and  condemnation  events 
remaining  to  be  assigned  to  rep  gen  events. 

NORTS(K)  Number  of  base  level  Reparable  This  Station  (RTS)  SRU  Type  K 
generations  remaining  to  be  assigned  to  rep  gen  events. 

NONRTS(K)  Number  of  base  level  NRTS  generations  remaining  to  be  assigned  to 
rep  gen  events. 

NOCON(K)  Number  of  base  condemnations  remaining  to  be  assigned  to  rep  gen 
events. 
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TABLE  III-4  (CONTD) 


NODCN(K)  Number  of  depot  condemnations  remaining  to  be  assigned  to  rep  gen 
events. 

NODRP(K)  Number  of  depot  repairs  remaining  to  be  assigned  to  rep  gen  events. 

LBRGN  Number  of  base  level  LRU  failures  in  the  current  quarter  (total  LRUs 

recorded  as  RTS  or  condemned. 


NOLEFT  Number  of  LRU  failures  that  have  not  yet  been  scheduled. 

LRTS  Number  of  LRU  RTS  events  that  have  not  yet  been  scheduled. 

NJOB  Job  number  associated  with  the  current  rep  gen  and  to  all  related 

exogenous  repair  events. 

LNRTS  Number  of  LRU  NRTS  events  in  the  current  quarter. 

LDRGN  Number  of  LRU  depot  rep  gens  in  the  current  quarter. 

LDCON  Number  of  LRU  depot  condemnations  in  the  current  quarter. 

LDCONT  NUMBER  OF  LRU  depot  condemnations  over  the  planning  horizon. 

LOVGNT  Number  of  NRTS  and  depot  LRU  generations  less  depot  condeman- 

tions  over  the  planning  horizon.  LOVGNT  thus  represents  the  total 
number  of  LRU  carcasses  received  at  the  depot  over  the  planning 
horizon. 

LDREP  Number  of  the  LOVGNT  LRUs  that  are  repaired. 

LOVCNT  Number  of  depot  LRU  overhaul  condemnations  over  the  planning 
horizon. 

NDRGN(K)  Number  of  depot  generations  of  SRU  K  over  the  planning  horizon. 

N1NDGN  (I,K)  Number  of  independent  depot  generations  for  SRU  K  in  quarter  I. 

NDCOND(K)  Number  of  depot  condemnations  of  SRU  K. 

NOVCNT(K)  Number  of  overhaul  condemantions  of  SRU  K  over  the  planning 
horizon. 

NSRUGN(K)  Total  SRU  NRTS  plus  total  SRU  depot  rep  gens  over  the  planning 
horizon. 

LRU  REP  =  LRU  Repair  Status  Flag. 

0  indicates  the  LRU  is  to  be  condemned. 

1  indicates  the  LRU  is  repairable. 

LRULOC  =  Base  number  associated  with  a  given  LRU  condemnation,  where 
LRULOC  =  0  indicates  a  depot  condemnation. 
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TABLE  III-5 

MONTE  CARLO  CALCULATION  FORMULAS 


A.  LRU  Base  Failure  Probabilities 

P  [  LRU  is  1  =  LBCOND/LBRGN 

J_  Condemned  J 

P  f  LRU  is  *1  =  LRTS/LBRGN 

L  RTS  J 

[SRU  K  is  defective  1 

in  a  given  LRU  base  =  NOSRUF(K)/  LBRGN*IQPA(K) 
rep  gen  J 

B.  Given  that  a  particular  SRU  K  unit  is  defective. 

P  r  SRU  K  1  =  NBRTS(K)/(NBRTS(K)  +  NBCOND(K)  +  NNRTS(K)) 

[is  RTS  J 

P  T  SRU  K  T  =  NBCOND(K)/(NBRTS(K)  +  NBCOND(K)  +  NNRTS(K» 

L  is  condemned] 

P  X  SRU  K  T  =  NNRTS(K)/(NBRTS(K)  +  NBCONEKK)  +  NNRTS(K)) 

L  is  NRTS  J 

C.  The  number  of  independent  base  SRU  rep  gens,  NOIND(K),  is  computed  as 
follows: 

If  LBRGN*IQPA(K)  NOSRUF(K),  then  NOIND(K)  =  0 
Otherwise,  NOINEKK)  =  NOSRUF(K)  -  LBRGN*IQPA(K) 


D.  SRU  depot  repair  probabilities 

[SRU  NRTS  1  =  NOVCNT(K)/(NOVCNT(K)  +  NODRPT(K)) 

is 

Overhaul  Condemned  J 

[SRU  NRTS  1  =  NODRPT(K)/(NOVCNT(K)  +  NODRPT(K)) 

is 

Repaired  j 
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Relationships  Among  Events  Generator  Variables 
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FIGURE  I I I- 7  (CONTINUED) 
DESCRIPTION  OF  SYMBOLS 


SYMBOL  DEFINITION 

*  Values  are  constructed  to 

be  exactly  the  same  as  historical 
values  on  a  quarter- by-quarter 
basis. 

+  Values  are  constructed  so 

that  the  totals  over  the 
planning  horizon  exactly 

equal  historical  values. 

These  values  are  derived 

from  other  variables. 

/  These  values  are  limited  to  be  no 

more  than  the  total  asset 
flow  through  this  point. 

K  SRU  Number. 

KK  K  ♦  1. 

KQ  Quarter  number. 


An  Example 


If  the  Write  Flag  IWT(10)  =  1,  all  events  which  are  entered  or  removed  from 
the  Future  Events  List  are  printed.  For  example,  Figure  111-8  illustrates  a  set  of  34 
events  placed  on  the  FEL  during  a  test  run  of  the  Events  Generator.  As  shown  in 
the  figure,  these  events  are  related  to  three  individual  LRU  reparable  generations. 
These  reparable  generations  are  assigned  job  numbers  of  1001,  1002,  and  1003, 
respectively.  The  first  LRU  reparable  generation  event  (Event  Code  14)  is 
scheduled  to  occur  at  base  #3  at  time  4444.  Consequently,  the  Stock  Keeping  Unit 
number  associated  with  this  event  is  4.  (The  reader  should  review  the  SKU 
numbering  rules  discussed  in  Chapter  D  to  verify  this).  Figure  III-8  shows  the  time, 
event  code,  Stock  Keeping  Unit  number,  quantity,  and  "priority/job  number"  code 
associated  with  each  generated  event.  Consequently,  the  first  line  of  this  Figure 
shows  that  a  Code  14  event  is  scheduled  at  time  4444  for  SKU  =  4.  Further,  this 
line  shows  that  only  1  asset  is  involved  and  that  a  reparable  generation  number 
NJOB  =  1001  has  been  assigned  to  this  reparable  generation  event.  The  second  line 
of  Figure  III-8  shows  that  a  requisition  to  replace  the  failed  LRU  is  scheduled  to 
occur  at  time  4454.  This  requisition  has  an  Event  Code  =  1,  the  SKU  =  4,  a 
quantity  of  1  unit  is  involved,  and  a  priority  code  of  1  has  been  assigned  indicating 
this  is  a  high  priority  requisition. 

The  third  line  of  Figure  UI-7  shows  that  at  time  4449  a  type  16  event  is 
scheduled,  indicating  that  the  LRU  (SKU  =  4)  begins  to  wait  for  SRU  components 
associated  with  the  LRU  failure  at  that  time.  For  this  event,  the  quantity  field 
equals  3,  indicating  that  the  total  number  of  SRU  components  required  to  complete 
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repair  of  the  LRU  is  NNEED  =  3.  Since  this  Begin  Wait  event  is  associated  with 
LRU  reparable  generation  1001,  the  job  number  1001  is  shown  in  the  right  hand 
column  for  this  event. 

Lines  4  through  10  of  Figure  M-8  show  the  SRU  events  associated  with  LRU 
reparable  generation  number  1001.  Events  4  and  3  represent  the  generation  of  one 
failed  unit  of  SRU  #1  at  base  3,  and  an  associated  requisition  for  a  serviceable 
unit,  respectively,  while  event  6  indicates  that  repair  of  this  failed  SRU  will  be 
completed  at  time  3444.  On  the  other  hand,  events  7  through  10  describe 
exogenous  events  associated  with  reparable  generations  of  SRU  #2.  Event  7 
records  the  generation  of  2  failed  units  of  SRU  #2;  the  right  hand  column  indicates 
these  failures  were  discovered  during  the  repair  of  LRU  job  number  1001.  Event  8 
indicates  a  requisition  for  2  serviceable  units  to  replace  the  failed  components  will 
reach  base  supply  at  time  4464.  On  the  other  hand,  events  9  and  10  describe  the 
disposition  of  the  failed  assets  of  SRU  #2.  Event  9  indicates  that  the  first  unit  of 
SRU  #2  to  be  removed  from  LRU  reparable  generation  1001  is  to  be  condemned 
(Event  Code  13)  at  time  4464,  and  event  10  shows  the  second  unit  of  SRU  #2 
removed  from  LRU  job  number  1001  is  also  condemned  at  base  level.  This  second 
condemnation  is  also  scheduled  to  occur  at  time  4464.  This  completes  the  list  of 
exogenous  events  associated  with  LRU  reparable  generation  number  1001. 

Events  11  through  22  describe  the  events  associated  with  the  second  LRU 
reparable  generation.  This  second  reparable  generation  is  assigned  the  job  number 
1002.  As  shown  for  event  11,  this  LRU  reparable  generation  is  scheduled  to  occur 
at  base  number  2  at  time  2643,  while  event  12  indicates  that  the  requisition  for  a 
serviceable  replacement  is  scheduled  to  reach  base  supply  at  time  2633.  In  this 
case,  three  replacement  SRU  units  are  needed  to  return  LRU  to  1002  a  serviceable 
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condition.  Event  13  records  the  start  of  a  "Begin  Wait"  status  for  the  LRU.  The 
LRU  will  remain  in  this  status  until  all  three  of  the  required  SRU  components  are 
obtained  from  base  supply.  Events  14  through  22  record  the  generation  of  the 
three  faulty  SRU  units  associated  with  LRU  failure  1002,  and  the  subsequent 
disposition  of  these  units.  Events  14,  13,  and  16  record  the  failure  of  a  single  unit 
of  SRU  #1  at  base  #2  and  its  subsequent  condemnation  at  that  base  (Event  Number 
16)  at  time  2663.  On  the  other  hand,  events  17  through  22  describe  the  generation 
and  subsequent  disposition  of  two  faulty  units  of  SRU  // 2  associated  with  LRU  rep 
gen  1002.  Event  17  records  the  generation  of  2  faulty  units  of  SRU  //2  at  time 
2658,  while  event  18  indicates  that  requisitions  for  serviceable  replacements  of 
these  units  reach  base  supply  at  time  2663.  Event  19  indicates  that  the  first  of 
these  failed  SRU  //2  units  is  shipped  to  the  depot  (a  NRTS  event)  at  time  2673, 
while  event  20  indicates  that  this  NRTS  asset  completes  depot  repair  at  time  7643. 
Finally,  event  21  shows  that  the  second  failed  unit  of  SRU  #2  associated  with  LRU 
rep  gen  1002  is  also  sent  to  the  depot  for  repair.  However,  event  22  indicates  that 
this  second  asset  is  condemned  at  the  depot  at  time  4643. 

Events  23  through  34  describe  the  exogenous  events  associated  with  the  third 
LRU  reparable  generation,  job  number  1003.  In  this  case,  the  LRU  reparable 
generation  is  scheduled  to  occur  at  time  498.  Events  associated  with  job  1003 
follow  a  pattern  similar  to  those  described  above  and  will  not  be  discussed  further 
here. 

The  specific  timing  for  a  given  LRU  reparable  generation  is  determined  by 
selecting  a  random  number  which  is  uniformly  distributed  over  the  quarter  of 
interest.  Once  the  specific  timing  of  LRU  rep  gen  has  been  determined,  all  related 
exogenous  events  are  scheduled  by  adding  appropriate  time  delays  to  the  time  of 
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LRU  reparable  generation.  Individual  exogenous  events  are  scheduled  (i.e.,  put  on 
the  FEL)  as  soon  as  the  need  for  the  event  is  established,  regardless  of  the  specific 
timing  of  the  event.  This  explains  why  the  first  LRU  reparable  generation  (job 
1001)  —  which  is  scheduled  to  occur  at  time  4444  —  is  placed  on  the  FEL  before 
LRU  rep  gen  1003,  which  is  scheduled  to  generate  at  time  498.  For  output, 
however,  all  exogenous  events  must  be  ordered  by  ascending  event  times.  This 
sorting  of  events  into  time  sequence  is  performed  by  subroutines  ENTER  and 
REMOVE.  When  the  need  for  a  given  event  is  determined,  subroutine  ENTER  is 
called,  and  the  five  data  elements  for  the  event  is  placed  into  its  appropriate  time 
sequence  on  the  Future  Events  List.  At  the  end  of  each  quarter,  subroutine 
REMOVE  is  called  to  remove  all  of  those  events  scheduled  to  occur  within  the 
given  quarter. 

If  the  Write  Flag  IWT(10)  =  1,  all  events  that  are  removed  from  the  Future 
Events  List  are  printed.  Figure  IU-9  shows  the  list  of  events  removed  from  the 
Future  Events  List  subsequent  to  the  scheduling  activities  described  in  Figure  M-8. 
As  shown  in  Figure  IU-9,  the  first  event  to  be  removed  from  the  FEL  is  the  Event 
Type  14  event  associated  with  reparable  generation  1003.  This  event  is  scheduled 
to  occur  at  time  498.  Although  this  was  the  23rd  event  to  be  generated  (see  Figure 
III-8),  it  has  the  lowest  scheduled  clock  time,  and  consequently  is  the  first  event  to 
be  removed  from  the  Future  Events  List.  Similarly,  the  second  event  to  be 
removed  from  the  FEL  is  the  Begin  Wait  event  (Event  Type  16)  associated  with 
LRU  reparable  generation  1003.  The  reader  may  verify  that  the  other  elements 
shown  in  Figure  III-9  correspond  to  the  time-sorted  values  of  Figure  III-8. 

Each  time  an  event  is  removed  from  the  Future  Events  List,  a  corresponding 
record  is  written  to  the  Exogenous  Event  File  (File  08).  Consequently,  at  the  end 
of  an  Events  Generator  run,  File  08  contains  a  list  of  exogenous  events  in  ascending 
time  sequence. 


FIGURE  III- 9 
EVENTS  GENERATOR  OUTPUT 
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CHAPTER  IV 


The  Levels  Computation  System 

The  Levels  Computation  System  provides  the  capability  to  compute  LRU  and 
SRU  stock  levels  using  the  METRIC,  MOD- METRIC,  VSL,  and  AFLCR  57-27  of 
requirements  computation  methodologies,  as  well  as  variations  of  these  methods. 
This  Chapter  describes  the  major  features  of  this  system. 


Stock  Level  Computations 


The  management  of  recoverable  item  inventories  involves  providing  answers  to 
three  basic  questions.  These  are: 

1.  When  will  recoverable  spares  be  needed? 

2.  How  much  is  needed? 

3.  Where  should  the  spares  be  located? 

The  first  two  questions  are  Procurement  issues,  for  they  determine  how  much  stock 
is  needed  to  support  a  given  system,  and  when  this  stock  should  be  acquired  and 
brought  into  the  Air  Force  supply  system.  The  third  question,  on  the  other  hand,  is 
a  Distribution  issue.  The  answer  to  this  question  determines  at  which  locations  the 
currently  available  stock  should  be  positioned. 

Two  distinct  phases  may  be  identified  during  the  life  cycle  of  a  given  item. 
These  are  the  Initial  Provisioning  Phase  and  the  Replenishment  Phase.  The  Initial 
Provisioning  Phase  determines  the  number  of  assets  which  will  be  acquired  during 
tne  initial  buy  of  an  asset,  while  the  Replenishment  Phase  determines  the  nunber 
of  additional  assets  which  are  required  to  compensate  for  (a)  condemnations 
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resulting  from  operations,  (b)  unexpectedly  high  failure  rates,  or  (c)  increased 
levels  of  program  activity.  Different  computational  methods  may  be  used  in  each 
of  these  phases  to  determine  recoverable  item  spares  requirements. 

As  noted  earlier,  we  wish  to  evaluate  the  relative  cost-effectiveness  of 
METRIC,  MOD-METRIC,  VSL,  AFLCR  57-6,  in  variants  of  these  methods  in 
managing  Air  Force  Recoverable  Items.  Some  of  the  interesting  variations  include 
the  use  of  one  of  these  techniques  for  initial  provisioning  and  a  second  technique 
for  decisions.  For  example,  the  Air  Force  currently  uses  MOD- METRIC  for  initial 
provisioning  of  major  end  items,  while  VSL  is  used  for  replenishment  calculations. 
None  of  the  above  methods  is  currently  used  for  distribution  of  Air  Force 
recoverable  spares,  but  work  is  currently  underway  to  develop  a  distribution  system 
based  upon  Sherbrooke's  METRIC  model. 

To  evaluate  each  of  these  alternate  methods,  we  needed  a  set  of  computer 
programs  to  perform  the  millions  of  required  calculations.  To  obtain  the  required 
computation  capability,  we  modified  the  family  of  programs  developed  to  imple¬ 
ment  the  MOD-METRIC  algorithm.  By  adjusting  input  data  to  these  programs,  and 
by  making  minor  changes  in  the  programs  themselves,  it  was  possible  to  compute 
stock  levels  using  all  13  sets  of  inventory  management  rules  that  were  of  interest 
in  this  study. 

Table  IV- 1  presents  the  relationship  between  the  family  of  MOD-METRIC 
computer  programs  and  the  specific  computational  methods  of  interest  in  this 
study.  As  shown  in  the  Table,  with  appropriate  input  data  the  MOD- METRIC 
program  ONEIND  can  be  used  to  perform  stock  level  computations  according  to  the 
assumptions  of  the  original  METRIC  mathematical  model.  Similarly,  the  program 
TWOIND  computes  levels  using  Muckstadt's  Mod-Metric  mathematics.  With 


CODES  EMPLOYED  TO  SIMULATE 
ALTERNATE  INVENTOI  Y  MANAGEMENT  METHODS 


slightly  different  manipulations  of  input  data,  Variable  Safety  Level  (VSL)  compu¬ 
tations  may  be  performed  using  the  ONEIND  program.  Unfortunately,  the  family 
of  MOD-METRIC  computer  programs  provided  no  way  of  computing  requirements 
using  lope  specified  in  AFLCR  57-27.  However,  Mr.  Terry  Mitchell  of  AFALD/ 
XRS  previously  implemented  a  CREATE  Time  Sharing  Program  to  accomplished 
this.  We  converted  Mr.  Mitchell's  program  to  a  subroutine  to  provide  an  AFLCR 
57-27  computation  capability  in  our  Stock  Levels  Computation  system. 

To  automate  the  levels  computation  process,  it  was  convenient  to  assign  codes 
to  identify  each  of  the  basic  stock  level  computation  methodologies.  These  codes 
are  shown  on  the  left-hand  side  of  Table  IV-1.  As  shown  in  the  table,  the  code 
IMETH  is  used  to  identify  the  computational  methodology  used  for  Initial  Pro¬ 
visioning  Calculations,  while  the  code  KMETH  is  used  to  specify  the  computational 
method  for  replenishment  computations.  Thus,  IMETH  =  1  indicates  that  the 
ONEIND  program  is  to  be  used  in  initial  provisioning  calculations  in  accordance 
with  METRIC  math  model  assumptions,  while  KMETH  =  1  indicates  the  same 
calculation  is  to  be  performed  during  the  replenishment  phase.  Similarly,  IMETH  = 
2  indicates  that  the  TWOIND  program  is  to  be  used  to  represent  MOD-METRIC 
calculation  methods  in  the  initial  provisioning  phrase,  while  KMETH  =  2  indicates 
TWOIND  is  to  be  used  for  replenishment  calculations. 

The  computation  codes  IMETH  and  KMETH  specify  the  general  computational 
method  to  be  used  for  Initial  Provisioning  and  Replenishment  Calculations, 
repsectively.  However,  three  other  pairs  of  codes  are  also  used  in  RIME  to 
completely  specify  a  stock  level  computation  method.  These  additional  codes  are 
defined  in  Tables  IV-2  and  IV-3. 
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(Discount)  or  (1.-  NRTS  fraction) 

NOTE:  IEQBAS  and  KEQBAS  are  used  in  prog-am  ONEIND  only;  no  other  program  ices  these  variables. 
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Table  IV -2  defines  two  additional  codes  defining  required  manipulations  of 
input  data  to  theONEIND  and  TWOIND  programs.  The  codes  IEQBAS  and  KEQBAS 
define  whether  or  not  base- to- base  differences  are  to  be  recognized  during  stock 
levels  computations.  If  the  code  equals  0,  base-to-base  differences  are  recog¬ 
nized.  On  the  other  hand,  if  the  code  equals  1  all  bases  are  assigned  to  be  equal. 
In  the  latter  case,  the  stock  level  computations  are  performed  by  replacing  input 
values  for  flying  hour  programs  and  order  and  ship  times  for  each  base  by  the 
respective  average  values  for  all  bases  combined.  This  latter  data  modification  is 
required  to  represent  the  Equal  Base  Assimption  employed  in  the  VSL  computation. 

The  codes  ICOST  and  KCOST  specify  whether  or  not  the  cost  discount 
computation  utilized  in  VSL  is  to  be  employed.  If  this  code  equals  zero,  stock 
level  computations  are  performed  without  any  modification  to  the  D041  unit  cost. 
On  the  other  hand,  if  the  code  equals  1,  the  D041  unit  cost  is  multiplied  by  a 
discount  factor  which  equals  the  greater  of  .10  or  (l.-NRTS  fraction).  Code  ICOST 
applies  to  initial  provisioning  predictions,  while  the  code  KCOST  specifies  tiie 
replenishment  calculation  method. 

Table  IV-3  specifies  four  variables  used  in  establishing  upper  and  lower  bounds 
upon  computed  stock  levels.  The  variables  I  MINSK  and  BOMINI  are  employed  to 
specify  bounds  on  initial  provisioning  calculations,  while  KMINSK  and  BOMINK 
specify  values  to  be  used  in  replenishment  decisions.  If  the  code  IMINSK  equals 
zero,  no  upper  or  lower  bounds  are  used  in  the  initial  provisioning  calculations.  On 
the  other  hand,  if  the  Bound  code  IMINSK  is  1,  all  stock  levels  are  computed  with  a 
lower  bound  equal  to  the  expected  number  of  assets  in  the  repair/ resupply  pipeline, 
and  an  upper  bound  specified  by  Upper  Bound  Variable  BOMINI.  Specific  nunerical 
values  for  upper  bounds  used  in  this  study  and  their  interpretation  are  given  in 
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Table  IV-3.  The  above  discussion  applies  to  the  variable  IMINSK  and  BOMINI  used 
to  bound  initial  provisioning  calculations.  However,  similar  comments  apply  to  the 
use  of  the  variables  KMINSK  and  BOMINK  used  to  bound  replenishment  stock 
levels. 

From  the  above  discussion,  ten  numerical  values  are  required  to  specify  an 
inventory  management  policy  for  both  initial  provisioning  and  replenishment 
calculations.  Five  codes  (IMETH,  IEQBAS,  ICOST,  IMINSK,  and  BOMINI)  are 
required  to  specify  an  inventory  management  policy  for  Initial  Provisioning 
calculations,  while  five  additional  codes  (KMETH,  KEQBAS,  KCOST,  KMINSK,  and 
BOMINK)  are  required  to  specify  Replenishment  calculations.  For  example,  Figure 
IV-1  illustrates  the  inventory  management  code  100-311  0  0/1  0.001.  As  shown  in 
the  table,  the  first  three  digits  (100)  specify  that  the  ONENID  program  is  to  be 
used  to  represent  the  METRIC  computation  algorithm;  base-to-base  differences 
are  to  be  recognized;  and  finally,  no  cost  discount  factors  are  to  be  employed.  The 
first  set  of  bounds  (0  0)  specify  that  no  upper  or  lower  limits  are  to  be  used  in  stock 
level  computations  for  initial  provisioning.  On  the  other  hand,  the  replenishment 
code  311  indicates  that  the  ONEIND  program  is  to  be  used  with  Variable  Safety 
Level  assunptions.  Since  KEQBAS  equals  1,  all  base  variables  are  to  be  set  to  the 
average  base  values  in  these  calculations.  Further,  since  KCOST  equals  1,  a 
discounted  unit  cost  is  to  be  used.  Finally,  the  set  of  bounds  (1  0.001)  indicate  that 
both  upper  and  lower  limits  are  to  be  applied  after  the  stock  levels  have  been 
computed.  The  lower  limit  is  to  be  the  expected  number  of  assets  in  the 
repair/ re  supply  pipeline,  while  the  upper  bound  on  base  stock  levels  is  to  be 
computed  based  upon  minimum  system  backorders  of  0.001. 


FIGURE  IV- 
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SPNDMS 


To  simplify  the  submission  of  RIME  evaluation  runs,  the  program  SPNDMS  was 
written  to  automate  the  preparation  of  input  data  and  Job  Control  Language 
statements.  Thirteen  specific  combinations  of  inventory  management  codes  are 
recorded  in  a  table  within  the  SPNDMS  program.  The  codes  included  in  this  table 
are  presented  in  Table  IV -4.  In  utilizing  SPNDMS,  the  program  asks  which  of  these 
13  rules  are  to  be  used  for  inventory  calculations.  It  then  obtains  the  required 
parameters  from  the  internal  table,  and  generates  the  JCL  required  to  implement 
the  calculations.  SPNDMS  is  discussed  further  in  Chapter  V;  in  the  following 
sections,  we  discuss  the  job  streams  generated  by  SPNDMS. 
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Alternate  Job  Streams  in  the  Levels  Computation  System 

All  Levels  System  job  streams  utilize  a  combination  of  MOD-METRIC 
programs  and  other  programs  specifically  written  for  the  RIME  system.  The 
MOD-METRIC  programs  ONEIND,  TWOIND,  GETBSO,  and  EVALUATE  are  essen¬ 
tially  identifical  to  the  AFLCR  57-6  MOD- METRIC  programs  with  minor  modifica¬ 
tions  required  for  the  incorporation  of  upper  and  lower  bounds.  The  programs 
SAVDAT,  GETDAT,  LEVLDP  and  SORT  were  specifically  written  for  RIME.  They 
provide  for  the  storage  and  sorting  of  stock  levels  data  produced  by  the  MOD- 
METRIC  routines. 

Figure  IV-2  illustrates  the  set  of  alternate  job  streams  which  might  be  utilized 
in  runs  of  the  Levels  Computation  System.  The  program  DMSGN1  is  a  key  element 
in  this  system  for  it  generates  the  input  records  required  by  all  the  MOD-METRIC 
|  computer  programs.  The  program  DMSGN1  first  obtains  LRU  and  SRU  descriptive 

data  from  the  Master  Data  Set,  and  writes  output  records  required  as  input  to 
MOD-METRIC  computational  programs.  Record  layouts  for  data  produced  by 
4  DMSGN1  are  presented  in  Section  III  of  Appendix  A. 

As  shown  in  Figure  IV-2,  records  used  to  drive  Initial  Provisioning  calculations 
are  written  to  file  12,  while  Replenishment  calculation  input  records  are  written  to 
;  file  R2.  Branches  on  the  left-hand  side  of  Figure  IV-2  correspond  to  Initial 

i 

Provision  Calculations,  while  those  on  the  right-hand  side  of  the  figure  correspond 
to  Replenishment.  The  Calculation  Codes  1METH  and  KMETH  specify  which  of 
the  specific  branches  will  be  followed  in  a  given  RIME  run. 

h 


As  shown  in  Table  IV-2,  setting  Code  IMETH  =  1  indicates  that  the  ONEIND 
computer  program  is  to  be  used  to  simulate  the  computation  of  stock  levels 
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Figure  IV-2.  The  Level  Computation  System 


according  to  the  METRIC  mathematical  model.  As  shown  in  Figure  IV- 2,  setting 
IMETH  =  1  specifies  that  the  job  stream  on  the  far  left  side  of  Figure  IV-2  is  to  be 
used  for  Initial  Provisioning  Calculations.  The  first  step  in  this  process  is  the  use 
of  the  program  ONEIND  to  compute  a  set  of  stock  levels  for  up  to  20  different  Buy 
Support  Objectives  (BSOs).  Details  of  these  calculations  are  printed  to  File  PI, 
while  the  stock  levels  and  associated  buy  suport  objectives  computed  by  ONEIND 
are  output  to  File  13.  File  13  serves  as  input  to  the  MOD-METRIC  program 
GETBSO.  The  GETBSO  program  reads  specified  buy  support  objectives  from  File 
05,  and  scans  the  set  of  buy  support  objectives  and  their  associated  stock  levels  on 
input  file  13.  In  performing  this  scan,  the  routine  GETBSO  attempts  to  find  a  set  of 
stock  levels  with  a  buy  support  objective  closest  to  the  desired  BSO.  Once  the 
required  stock  levels  are  found,  GETBSO  writes  these  levels  to  the  output  file  16. 

Suppose  that  the  Computation  Code  for  replenishment  calculations  KMETH  is 
also  set  to  1.  As  shown  in  Figure  IV-2,  this  indicates  that  the  MOD-METRIC 
program  ONEIND  is  also  to  be  used  to  compute  stock  levels  for  Replenishment 
calculations,  while  GETBSO  is  to  be  used  to  determine  the  specific  stock  levels 
associated  with  each  desired  buy  support  objectives.  These  levels  are  then  output 
to  File  R6. 

As  shown  in  the  figure,  replenishment  stock  levels  are  always  written  to  File 
R6.  At  the  conclusion  of  a  Levels  Computation  System  run,  Initial  Provisioning 
stock  levels  on  File  16  and  Replenishment  stock  levels  on  File  R6  are  merged, 
sorted,  and  the  resulting  records  are  output  to  the  "Levels  File"  A3.  This  file  is 
one  of  major  inputs  to  the  RIME  simulation  model. 

Before  leaving  this  section,  let  us  briefly  discuss  each  of  the  other  job  streams 
illustrated  in  Figure  IV-2.  If  the  computation  Code  IMETH  is  set  to  2,  the 
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MOD-METRIC  program  TWOIND  is  used  to  compute  stock  levels  according  to 
Muskstadfs  multi-indenture,  multi-echelon  mathematical  model.  This  program  is 
similar  to  the  ONEIND  program  in  that  it  computes  stock  levels  for  a  range  of  buy 
support  objectives.  The  set  of  levels  computed  by  TWOIND  is  then  written  to  the 
output  file  13.  In  turn,  file  13  serves  as  input  to  the  program  GETBSO.  GETBSO 
then  reads  the  desired  buy  support  objectives  from  Logical  Unit  05  and  scans  the 
levels  file  13  to  find  a  set  of  levels  whose  buy  support  objective  is  closest  to  the 
desired  BSO.  The  resulting  levels  are  output  to  File  16.  Essentially  the  same 
calculations  are  performed  when  the  replenishment  Computation  Code  KMETH  =  2. 
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As  shown  in  Table  IV -2,  setting  the  Computation  Code  IMETH  equal  to  3 indicates 
that  the  Variable  Safety  Level  (VSL)  calculation  is  to  be  used  in  Initial  Provisioning 
to  determine  the  total  number  of  assets  to  be  procured,  while  the  METRIC  math 
model  is  to  be  used  to  determine  the  distribution  of  these  assets.  As  shown  in 
Figure  IV-2,  implementation  of  this  computation  requires  several  job  steps.  First, 
program  SAV  DAT  is  called.  This  program  stores  the  MODMETRIC  item  identification 
and  job  control  cards  on  the  random  file  Ml.  This  file  is  used  later  in  the  job  stream 
as  input  to  the  program  GETDAT.  After  SAVSAT  stores  this  inform  anti  on,  the 
program  ONEIND  is  used  to  compute  stock  levels.  When  IMETH  =3,  ONE  IN  D  performs 
these  computations  assuming  that  all  bases  are  equal.  Stock  levels  computed 
by  ONEIND  are  output  to  file  13,  which  provides  input  to  the  program  GETBSO. 
In  turn,  GETBSO  determines  the  set  of  stock  levels  associated  with  the  desired 
BSCs,  and  outputs  these  stock  levels  to  file  14. 

The  program  GETDAT  reads  the  sets  of  stock  level  from  file  14,  and  obtains 
unit  cost,  NRTS  rate,  failure  rate,  and  other  item  decription  data  from  the  random 
file  Ml.  GETDAT  then  uses  this  information  to  construct  a  set  of  data  cards  for 
input  to  the  MODMETRIC  program  EVALUATE.  In  doing  this,  GETDAT  computes 
the  total  number  of  assets  associated  with  each  desired  buy  support  objective  by 
summing  the  stock  levels  for  the  depot  and  for  each  base.  It  then  outputs  a 
MODMETRIC  "delivery  schedule"  card  with  the  computed  asset  total  in  the  first 
quarter  deliveries  field.  The  program  EVALUATE  then  reads  this  total  number  of 
assets,  and  determines  the  optimun  distribution  of  these  assets  among  the  depot  and 
using  bases.  In  performing  its  calculation,  EVALUATE  recognizes  base- to- base 
LRU/SRU  relationships. 

Finally,  stock  levels  computed  by  EVALUATE  are  output  to  File  16.  If  the 
Replenishment  Computation  Code  KMETH  =  3,  calculations  are  similar  to  those  for 
IMETH  =  3,  but  in  this  case  the  computed  stock  levels  are  written  to  the  file  R6. 
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A  final  possibility  is  that  the  Initial  Provisioning  Computation  Code  IMETH  is 
set  to  4,  indicating  that  logic  specified  in  AFLCR  57-27  is  to  be  used  for  Initial 
Provisioning  calculations.  When  this  option  is  specified,  program  DMSGN1  calls 
subroutine  INTPRO  to  compute  the  total  number  of  assets  associated  with  AFLCR 
57-27  logic.  This  total  is  recorded  in  the  part  number  identification  field  of  the 
MODMETRIC  delivery  schedule  card  is  also  output  to  file  12.  Later  in  the  job 
stream,  program  EVALUATE  is  used  to  determine  distribution  of  the  total  number 
of  AFLCR  57-27  assets  among  each  of  the  using  bases.  Stock  levels  computed  by 
EVALUATE  are  output  to  file  14. 

The  RIME  Simiulation  Model  expects  to  find  separate  sets  of  stock  levels  for 
each  Buy  Support  Objective  to  be  evaluated.  However,  a  desired  buy  support 
objective  is  not  a  factor  in  the  AFLCR  57-27  computation  logic,  and  AFLCR  57-27 
logic  always  computes  the  same  requirement  regardless  of  the  specified  BSO. 
Consequently,  the  program  LEVLDP  is  used  to  create  duplicates  of  the  AFLCR  57- 
27  stock  levels  output  from  EVALUATE.  To  do  this.  LEVLDP  reads  the  BSO  file, 
and  counts  the  number  of  BSO  records  on  this  file.  It  then  creates  a  like  numver  of 
duplicates  of  each  stock  level  record  on  file  14,  and  writes  ail  of  these  levels 
records  to  file  16.  Stock  levels  on  file  14  are  then  merged  and  sorted  with  the 
replenishment  levels  on  file  R6. 


Note:  Setting  KMETH  =4  is  not  a  legal  option  in  the  Levels  Computations  System. 
That  is,  AFLCR  57-27  logic  cannot  be  used  in  preforming  replenishment  calcula¬ 


tions. 
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Using  the  Recoverable  Item  Management  Evaluator 
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Introduction 

To  exercise  the  Recoverable  Item  Management  Evaluator  (RIME),  the  user 
must  perform  three  major  steps.  These  are: 

1.  Construct  a  Master  Data  Set  containing  required  information  on  all  LRUs 
and  SRUs  to  be  included  in  the  evaluation  calculations. 

2.  Utilize  the  Events  Generator  to  create  an  exogenous  event  file  to  drive  the 
Simulation  Model. 

3.  Utilize  the  program  SPNDMS.O  to  generate  stock  levels  according  to 
specified  criteria,  and  to  initiate  a  simulation  run. 

Let  us  now  consider  each  of  these  steps  in  more  detail. 

Generating  the  Master  Data  Set 

To  utilize  the  Recoverable  Item  Management  Evaluator  the  user  must  provide 
item  description  and  historical  reparable  generation  data  for  each  LRU  and  SRU  to 
be  evaluated.  Required  formats  for  this  information  are  documented  in  Appendix 
A  of  this  report.  Definitions  of  associated  FORTRAN  input  variables  used  in  the 
RIME  system  are  defined  as  part  of  the  record  layouts  presented  in  Appendix  A. 
These  data  elements  are  designed  to  closely  correspond  to  data  elements  in  the 
D041  Recoverable  Consumption  Item  Requirements  System. 


Using  the  Events  Generator 


The  file  EVTGNJK  contains  3ob  Control  Language  (3CL)  required  to  exercise 
the  Events  Generator.  A  listing  of  EVTGN.A  is  shown  in  Figure  V-l.  The 
’’SELECT"  cards  are  used  to  select  compiled  object  programs  for  each  of  the 
routines  used  by  the  Events  Generator  for  use  in  the  current  run.  Lines  210,  220, 
and  225  specify  input  parameters  which  control  the  EVTGN.A  run. 

Table  V-l  defines  the  input  parameters  required  as  the  first  two  lines  of  input 
to  the  EVTGN.A  run.  The  first  record  specifies  the  set  of  LRU/SRU  groups  to  be 
selected  from  the  Master  Data  Set  taring  this  run,  while  the  variable  NBASES 
specifies  the  number  of  operating  bases  to  be  assumed  during  the  events  generation 
process.  The  variables  1NQTR  and  NREPL  specify  the  number  of  quarters  in  the 
simulation  planning  horizon  and  the  number  of  replications  of  the  events  generation 
process  to  be  performed,  respectively.  For  example,  line  210  of  Figure  V-l 
specifies  that  LRU/SRU  groups  1  thru  3  we  to  be  included  in  the  current  EVTGN.A 
run.  In  performing  tile  events  generation  process,  line  210  specifies  that  6  bases 
are  to  be  assumed,  that  the  events  generation  process  is  to  utilize  a  16-quarter 
planning  horizon  and  two  replications  of  the  events  generation  process  are  to  be 
performed  for  each  LRU/SRU  group. 

The  second  input  line  of  EVTGN.A  specifies  a  set  of  "Write"  flags  which 
specify  output  options  to  be  employed  during  the  current  simulation  run.  These 
flags  are  defined  in  Table  III- 3.  Finally,  line  225  of  Figure  V-l  specifies  an  ASCII 
Input  file  which  contains  base  order  and  ship  time  information,  as  well  as  data 
describing  flying  hour  programs  by  base  for  each  period  to  be  simulated.  Table  V-2 
defines  the  variables  which  are  specified  by  this  file,  while  Table  V-3  illustrates 
the  structure  of  this  file.  As  shown  in  Table  V-2,  the  first  line  of  this  file  specifies 
tiie  number  of  bases,  NBASES,  for  which  data  is  provided  in  this  file.  In  addition, 
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Table  V-l 

EVTGN.A  Input  Parameters 


Variables 


NFGRP,  NFGRP,  NBASES,  INQTR,  NREPL 
Write  Flags  (IWT(0, 1  =  1,20) 


NFGRP 

s  The  number  of  the  first  LRU/SRU  group  to 

be  included  in  the  Events  Generation  Pro¬ 
cess. 

NLGRP 

*  The  number  of  the  last  LRU/SRU  group  to 

be  included  in  the  Events  Generation  Pro¬ 
cess. 

NBASES 

*  The  nunber  of  operating  bases  assumed  in 

events  feneration.  This  value  overrides  the 
number  of  bases  specified  in  the  Base  OSf/ 
Flyine  Proxram  File. 

INQTR 

=  The  number  of  quarters  of  events  to  be 

generated  (INQTR  must  not  exceed  16). 

NREPL 

s  The  nunber  of  replications  of  the  event 

generation  process  to  be  performed  for  each 
LRU/SRU  g^oup. 

IWT(D 

*  Write  Flag  I.  See  Table  III-3  for  definitions 

of  output  options  controlled  by  IWTtD. 
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Table  V-2 

Base  OicST  and  Flying  Program  Input  File 


Record 

No.  Data  Elements 


1  LINE,  NBASES,  (OSTDLT(K),  K  =  1,  NBASES) 

2  LINE,  IDATE,  (BFH(I,K),  K  =  1  NBASES) 

3,4,5. . .  Information  in  the  format  of  Record  #2  must  be  provided  for  each 
quarter  to  be  sim  dated,  in  ascending  time  sequence. 


Definitions 


LINE  = 

A  Time-Sharing  File  line  number. 

NBASES 

The  number  of  operating  bases  associated 
with  this  data  file. 

OSTDLT(K)  = 

The  deviation  of  the  average  depot  order 
and  ship  time  at  base  K  from  the  worldwide 
average  depot  order  and  ship  time. 

IDATE  = 

The  date  associated  with  flying  program 
data  on  this  input  line.  This  variahle  is  not 
used  in  any  calculations. 

BFH(I,  K) 

Flying  program  at  base  K  in  quarter  I. 
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Table  V-3. 

A  Sample  Base  Data  Input  File. 
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the  first  line  of  tills  file  also  specifies  values  for  computing  the  Order  and  Ship 
Time  (O&ST)  for  an  individual  base  once  the  worldwide  average  OST  value  is 
known.  The  remaining  lines  in  the  file  specify  the  flying  program  activity  by  base 
for  each  of  the  quarters  to  be  simulated. 

In  Figure  V-l,  line  230  specifies  the  data  tape  which  contains  the  Master  Data 
Set,  while  line  240  specifies  the  data  tape  that  is  to  contain  the  Exogenous  Event 
File.  This  latter  tape  then  becomes  the  major  input  element  to  the  RIME 
Simulation  Model. 

Using  SPNDMS.O  to  Generate  RIME  Simulation  Runs 

To  exercise  the  Levels  Computation  System  and  to  initiate  an  associated 
simulation  run,  it  is  necessary  to: 

1.  Provide  appropriate  input  parameters  to  the  program  DMSGN1  which 
specify  the  specific  initial  Provisioning  and  Replenishment  calculations  to  be 
performed,  and 

2.  Create  an  appropriate  set  of  Sob  Control  Language  commands  to  bring  the 
required  levels  of  computation  programs  into  use,  and  to  control  input/output  files 
which  interconnect  these  programs.  This  is  a  substantial  task,  since  several 
hundred  3CL  cards  may  be  required  for  certain  types  of  stock  levels  computations. 
Fortunately,  many  of  the  required  input  parameters  remain  constant  in  performing 
a  given  study  of  proposed  inventory  management  methods.  This  was  true  in  our 
case.  Consequently,  we  developed  the  program  SPNDMS  to  automate  a  major 
portion  of  the  run  specification  task. 


The  Levels  Computation  System  Input 
major  types  of  input  data.  One  of  these  id 


data  generator  DMSGN1  requires  two 
the  Master  Data  Set  discussed  above. 


The  other  major  input  is  a  set  of  parameters  which  specify  the  specific  stock 
leveling  calculations  to  be  performed  in  a  given  run.  Table  V-4  defines  these 
required  input  parameters.  The  FORTRAN  variable  names  used  in  program 
DMSGN1  are  shown  in  Table  V-4.  All  of  these  values  are  read  using  a  Free-Field 
input  format. 

As  shown  in  Table  V-4,  the  first  two  input  lines  to  DMSGN1  specify  the 
Computation  Codes  needed  to  define  required  Initial  Provisioning  and  Replenish¬ 
ment  calculations.  The  third  input  record  specifies  the  set  of  LRU/SRU  groups  to 
be  included  in  the  current  run,  the  number  of  quarters  for  which  levels  are  to  be 
computed,  and  a  value  of  the  variable  NDHIS.  The  fourth  input  line  specifies  the 
set  of  Write  Flags  to  be  employed  in  the  current  run.  Definitions  of  these  DMSGN1 
Write  Flags  are  presented  in  Table  V-5. 

Input  lines  5  thru  7  specify  values  to  be  used  in  MOD-METRIC  computer 
program  control  cards.  These  parameters  are  defined  in  AFLCR  57-6,  and  will  not 
be  discussed  further  here.  Finally,  the  remaining  input  cards  to  DMSGN1  specify 
the  base  Order  and  Ship  Time  calculation  variables  and  flying  hour  programs  by 
base  to  be  used  for  the  current  computation  run.  These  latter  inputs  are  the  same 
as  those  defined  in  Table  V-2. 

Fortunately,  it  is  not  necessary  for  the  user  to  specify  these  data  cards  each 
time  he  wishes  to  exercise  the  RIME  system.  Rather,  the  program  SPNDMS  may 
be  used  to  automate  most  of  this  process. 

Using  SPNDMS 


The  compiled  program  SPNDMS.O  is  a  FORTRAN  Time-Sharing  program 
which  automates  many  of  die  steps  required  in  the  preparation  of  input  data  and 
associated  3CL  statement  required  in  the  use  of  the  RIME  model.  Figure  V-2 


DMSGN1  Input  Parameters 
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#NDHIS  =  The  number  of  data  periods  to  be  considered  as  past  history  in  performing  levels 

catenations  at  simulation  time  zero,  performining  levels  calctiations.  For  most  RIME 
applications,  NDHIS  should  be  zero. 
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Table  V-5 

DMSGN1  Write  Flag 

Write  Flag 

Number  Routine  Effect 


1  READFl  Input  data  print  flag,  where 

1  =  print  short  header  record  only 

2  =  print  short  header  and  rep  gen  data 

3  =  print  all  input  data 

2  READFL  Print  item  data  written  to  Exogenous  Event  File 

(In  DMSGN  1,  this  flag  should  always  equal  zero.) 

3  DMSGN1  Print  intermediate  data  generation  calculations 

4  METINP  Print  details  of  MTBD,  NRTS,  and  condemnation 

rate  estimates. 

5  INTPRO  Print  initial  provisioning  calculations 

6  OVHSTL  Print  overhaul  stock  level  calculations. 

7-20  -  These  flags  are  not  used. 
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illustrates  the  use  of  this  program  for  initiating  a  particular  RIME  simulation  run. 
As  may  be  seen  in  the  Figure,  SPNDMS.O  asks  the  reader  several  questions. 
Answers  to  Question  #1  define  where  outputs  from  the  current  run  are  to  be 
directed  and  the  size  of  the  runs  to  be  performed.  Questions  #2  and  #3  define  the 
JCL  control  card  which  identifies  the  Exogenous  Event  File  to  be  used  as  input  to 
the  Simulation  Model.  Question  #4  asks  for  the  values  of  NFGRP,  NLGRP,  INQTR, 
and  NDHIS  to  be  provided  as  input  to  DMSGN1.  It  also  asks  for  the  maximum 
amount  of  CPU  time  to  be  used  in  the  current  run  specified  in  hundredths  of 
CPU-hours.  Finally,  Question  #5  asks  for  the  formula  number  to  be  evaluated  in 
the  current  RIME  run.  Values  for  the  13  Computation  Codes  required  to  specify 
Initial  Provisioning  and  Replenishment  calculations  defined  in  Table  IV- 4  are 
recorded  in  a  table  within  the  SPNDMS  program.  After  the  user  specifies  the 
required  formula  number,  SPNDMSdoes  a  table  lookup  to  determine  the  values  for 
the  variables  IMETH,  IEQBAS,  and  so  on,  and  SPNDMS  then  prints  these  values  at 
the  user's  terminal.  Next,  SPNDMS  accesses  the  specific  files  of  JCL  statements 
required  to  implement  the  desired  calculations.  Once  the  set  of  required  input 
parameters  in  Job  Control  Language  statements  have  been  accumulated,  SPNDMS 
submits  the  entire  set  of  JCL  records  to  the  CREATE  batch  processing  system. 
The  CREATE  control  number  assigned  to  the  batch  job  is  then  printed  at  the  user's 
terminal.  In  Figure  V-2,  the  job  number  g363t  was  assigned. 

In  Question  #6,  SPNDMS  asks  if  any  more  evaluation  runs  are  to  be  launched 
for  the  current  set  of  LRU/SRU  groups.  If  the  user  answers  yes,  program  logic 
returns  to  Question  #5.  Otherwise,  SPNDMS  asks  Question  #7.  Question  #7  asks  if 
the  user  wishes  to  continue  generating  RIME  evaluation  runs,  or  if  he  wishes  to 
terminate  the  current  session  with  SPNDMS.  If  the  user  wishes  to  continue, 
program  logic  returns  to  Question  #1.  Otherwise,  SPNDMS  terminates  its  run. 


RUN  SPNDMS « 0 

AC' r  PUNCH?  SIMULATE?  MORE  CORE?  <1=YES,  0=N0 

zL.  JL  -L  JL 

IS  t: TAPE  107 >X9D»  *70053* t EXOGF 

OK  FOR.  EXOGFILE?  <Y-YES> 

~N_ 

INPUT  EXOGFILE  CONTROL  CARD 
»♦ : TAPE « 07 r X9D>  >727 .RIME2 
CARD  WAS  READ  AS-- 
■■■»■* ITAPE:07fX9Df  *72774, *RIME2 
IS  CARD  OK? < Y  OR  N) 

NFGRP *  NL6RP* INQTR.NDHIS*  CPU-LIMIT 
-  1  3  16  0  15 


^-Question  #1 
^-Question  #2 


♦-Question  #3 


-Question  #4 


I DENT? 

-i 


•Question  #5 


IDENT  IMETH  IEQBAS  ICOST  KMETH  KEQBAS  KGOST 


IMINSK  DOMINI  KMINSK  DOMINK 
00*  00. 
SNUMB  *  S365t 
CONTINUE? < Y  OR  N?) 

*iL 

DO  ANOTHER  GROUP? <Y  OR  N) 

-it 


-Question  #6 
-Question  17 


*NOTEs  See  Table  V-6  for  further  description  of 
these  questions. 


Figure  V»2.  An  Illustration  of  the  Use  of  SPNDMS. O  to 
Initiate  a  RIME  Evaluation  Run. 


Question  #1  (1 
AC? 

PUNCH? 

SIMULATE? 

MORE  CORE? 

Question  #4 
NFGRP 

NLGRP 

INQTR 

NDHIS 

CPU-LIMIT 
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Table  V-6 

SPNDMS.O  Input  Parameters 


=  Yes.  0  =  No) 


Is  the  output  for  this  job  to  be  directed  to  station  code  AC?  If 
not,  output  is  printed  at  the  CREATE  Central  Site. 

Are  the  computed  stock  levels  to  be  output  on  punched  cards? 

Is  the  RIME  Simulation  Model  to  be  used  (1  =  YES).  Otherwise, 
the  run  terminates  after  all  stock  levels  have  been  computed. 

Does  the  current  run  involve  more  than  40  Stock  Keeping  Units 
for  the  largest  IRU/SRU  family  to  be  considered?  If  so,  more 
core  is  needed. 


The  number  of  first  LRU/SRU  group  to  be  included  in 
calciiation. 

The  number  of  the  last  LRU/SRU  group. 

The  number  of  quarters  in  Planning  Horizon 

The  number  of  quarters  of  input  data  to  be  considered 
as  past  history  at  simulation  time  zero.  For  most  RIME 
applications,  set  NDHIS  =  0. 

Job  time  limit  for  the  current  run  in  hundredths  of 
CPU- hours. 


RIME  Simulation  Model  Input/Output  Files 

Figure  V-3  illustrates  the  input  and  output  files  utilized  by  the  RIME 
Simulation  Model,  and  the  associated  Logical  Unit  Designators.  As  shown  in  the 
figure,  Logical  Units  05,  07,  and  09  provide  the  inputs  to  the  Simulation  Model, 
while  logical  units  06,  15,  16,  and  43  are  output  files.  Logical  unit  11  is  a  work  file 
used  for  the  temporary  storage  of  stock  level  data. 

Logical  Unit  05  specifies  run  parameters  and  output  options  to  be  used  in  the 
control  of  the  current  simulation  run.  Logical  Unit  07  is  associated  with  the 
Exogenous  Event  File,  while  Logical  Unit  09  is  associated  with  the  set  of  Stock 
Levels  to  be  evaluated  during  the  current  simulation  run.  The  Stock  Levels  File  is 
a  sequencial  file.  To  simplfy  processing,  this  file  is  read  in  sequential  order  by 
subroutine  INITMi  at  the  beginning  of  a  RIME  run,  and  stock  levels  read  from  this 
file  are  recorded  on  the  random  file  11.  Stock  levels  are  then  obtained  as  needed 
by  subroutine  LEVEL  from  file  11  during  the  simulation  run.  This  greatly  simplifies 
the  processing  of  mutiple  replication  evaluation  runs. 

The  Simulation  Model  provides  outputs  to  report  codes  06, 15,  and  16,  and  also 
provides  punched  card  results  to  logical  unit  43.  The  Summary  and  Short-Form 
Reports  are  printed  to  file  06,  while  files  15  and  16  are  used  to  print  8-  and 
16-quarter  totals  of  selected  statistics.  The  information  printed  on  files  15  and  16 
is  also  punched  on  logical  unit  43  if  the  flag  ITWRT  =  2. 

Details  of  the  Exogenous  Event  File  and  the  Stock  Levels  File  have  been 


discussed  in  previous  sections,  and  will  not  be  considered  further  here.  In  the 
following  sections,  we  discuss  the  features  of  the  Run  Parameter  file,  and  of  the 
output  options  available  to  users  of  the  RIME  Simulation  Model. 


Figure  V-3.  Rime  Simulation  Model  Input  and  Output  Files 


Run  Parameters  File 


The  Run  Parameters  File  (Logical  Unit  05)  specifies  variables  which  control 
the  size  of  the  current  simulation  run,  and  the  output  products  to  be  produced  as  a 
|  result  of  this  run.  Table  V-7  defines  the  variables  specified  in  this  file,  while 

Figure  V-4  illustrates  a  "print-back"  of  Run  Parameter  data  produced  in  a  sample 
Simulation  Model  run. 

|  As  shown  in  Table  V-7,  the  first  set  of  Run  Parameters  are  specified  in  the 

header  record  of  the  Exogenous  Event  File  (Logical  Unit  07).  This  record  specifies 
the  set  of  LRU  groups  to  be  included  in  the  current  run,  and  the  number  of  bases, 

,  the  length  of  the  planning  horizon  and  the  number  of  replications  for  which 

exogenous  events  are  provided.  This  record  is  created  automatically  during  the 
Events  Generator  run.  The  remaining  Run  Parameters  are  provided  in  free-field 
format  on  Logical  Unit  05.  The  first  record  on  Logical  Unit  05  specifies  four 
Output  Controls,  while  the  second  record  specifies  values  for  7  "debug"  flags.  The 
Debug  flags  are  useful  in  the  development  of  new  programs  for  the  Simulation 
Model.  Finally,  the  third  input  record  specifies  the  size  of  the  simulation  run  to  be 
performed.  Definitions  of  these  parameters  are  presented  in  Table  V-4. 

RIME  Output  Products 

1  As  discussed  in  Chapter  11,  all  RIME  performance  statistics  have  three 

different  indices.  For  example,  the  Performance  Statistic  IREQT(I,  3,  K)  records 
the  total  number  of  requisitions  received  from  customers  of  the  supply  organiza- 
i  tion.  The  index  I  denotes  the  quarter  in  which  the  requisition  was  received.  The 

index  3  records  the  type  of  measure  associated  with  this  statistic,  where  3  =  1 
denotes  the  number  of  distinct  federal  stock  numbers  or  distinct  actions  associated 
i 


Table  V-7 


Simulation  Model  Control  Parameters 


(Cl)  Exogenous  Event  File  Characteristics 

Note:  The  following  variables  are  read  from  the  header  record  of  the 
Exogenous  Event  File  (EEF)  on  Logical  Unit  07. 


NFGRP 

NLGRP 

NBASES 

NNQTR 

NREPL 


The  number  of  the  first  LRU  group  on  the  EEF. 

The  number  of  the  last  LRU  group  on  the  EEF. 

The  number  of  bases  assumed  in  the  EEF. 

The  number  of  quarters  of  events  on  the  EEF. 

The  number  of  replications  performed  for  each  LRU  group. 


(C2)  Output  Controls. . .  (Note.  1  =  YES) 


ITWRT  =  The  item  "write"  flag.  If  ITWRT  ■  1  or  2,  subroutine  ITRSLT 
called  to  punch  ten  major  statistics  for  each  replication  of  each 
LRU  group.  If  ITWRT  ■  1,  cummuiatWe  values  through  quarters 
S  and  INQTR,  respectively,  are  punched.  If  ITWRT  *  2,  the 
statistics  are  punched  for  each  of  the  MQTR  quarters  simu- 


Table  V-7  (Continued) 


lOUT  =  Detailed  Summary  Flag.  If  this  flag  equals  1,  the  Detailed 
Summary  Report  is  produced  for  each  Buy  Support  Objective 
(BSO)  evaluated.  This  option  produces  approximately  1800  lines 
of  output  for  each  BSO. 

IGRAPH  =  The  Plot  Flag.  This  option  is  not  implemented  in  the  current 
version  of  RIME. 

ISUMRY  =  The  Short  Form  Summary  Flag.  If  this  parameter  equals  1,  the 
Short  Form  Summary  Report  is  produced  after  for  Buy  Support 
Objective  evaluated. 


(C3)  Debug  Flags. 

Note:  These  variables  specify  print  options  useful  in  debugging  new  RIME 

routines. 

ID  BUG  .  =  The  File  Debugging  Flag.  If  IDBUG  =  1,  the  following  actions 
are  taken: 

(a)  All  entries  and  removals  from  the  Future  Events  List 
are  printed. 

(b)  All  entries  and  removals  from  the  Work-in-Process  file 
are  printed. 


(c)  All  entries  and  removals  to  the  Backorder  File  are 


Table  V-7  (Continued) 


(d)  Values  of  on -hand,  on-order,  work-in-process  stock,  and 
backorders  are  printed  after  each  event. 


(e)  The  Stock  Status  Trace  Report  is  produced. 


IEDUG 

IFBUG 


IGBUG 

IHBUG 


The  Item  Input  Data  Flag.  If  IEDUG  =  1,  all  LRU/SRU  item 
description  data  input  from  file  07  is  printed. 

The  Item  Forecast  Flag.  If  IFBUG  =  I,  details  of  endogenous 
item  forecasting  calculations  are  printed,  (fin  the  current 
version  of  RIME,  forecasting  calculations  are  exogenous  events. 
Consequently,  this  flag  has  no  effect.) 

Statistic  Update  Flag.  If  IGBUG  =  1,  the  results  of  statistics 
updates  in  routines  CUM  and  CUMB  are  printed. 

Levels  Calculations  Flag.  If  IHBUG  =  1,  the  results  of  all  stock 
levels  calculations  are  printed. 


(C8)  Simulation  Size  Parameters. 


NLAM  =  The  number  of  Buy  Sipport  Objectives  (LAMBDAS)  to  be 
evaluated. 

INQTR  =  The  number  of  quarters  to  be  simulated.  This  number  must  not 
exceed  the  value  NNQTR  read  from  the  header  record  of  the 
Exogenous  Event  File. 

The  total  number  of  LRU  groups  to  be  simulated  in  the  current 
run.  This  value  must  no^  exceed  (NLGRP  -  NFGRP  ♦  l). 


NTOTL 


Figure  V-4 .  RIME  Simulation  Model  Control  Parameters. 
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with  the  current  event,  3  =  2  denotes  the  number  of  units  associated  with  the 
event,  and  3  =  3  denotes  the  dollar  value  of  ail  units  associated  with  the  event. 
Finally,  the  index  K  denotes  the  aggregation  category  for  the  statistic.  Values  of 
K  and  their  meaning  are  as  follows: 


Aggregation 

Index 

Value  Definition 

1  LRU  at  base  level 

2  SRU  at  base  level 


3  LRU  at  the  depot 

4  SRU  at  the  depot 

5  SRU  at  the  Aircraft  Overhaul  Facility 

6  SRU  at  the  Aircraft  Overhaul  Facility 


For  example,  sij>pose  that  a  requisition  for  12  units  of  a  $10  item  is  received 
at  a  base  during  the  fourth  quarter  of  the  simulation.  In  this  case,  the  period  index 
is  I  =  4.  Consequently,  the  RIME  statistic  IREQT(4,  1,  1)  is  increased  by  1  to 
record  this  order  action.  Since  12  units  were  ordered,  the  statistic  IREQT(4,  2,  1) 
is  increased  by  12,  and  the  statistic  IREQT(4,  3, 1)  is  increased  by  120  to  record  the 
dollar  value  of  the  requisition. 

As  discussed  in  Chapter  II,  RIME  collects  32  different  statistics,  for  16 
distinct  quarters.  To  print  all  of  the  statistics  collected  in  a  single  replication  of 
the  RIME  model  results  in  a  very  large  volume  of  output. 


Detailed  Summary  Report,  If  the  input  parameter  IOUT  =  1,  RIME  prints  the 
Detailed  Summary  Report  to  Logical  Unit  06.  This  report  prints  the  values  of 
every  RIME  performance  statistic,  an  output  of  approximately  1800  lines  for  each 
Buy  Support  Objective  evaluated.  Figures  V-5  thru  V-8  illustrate  the  format  of 
this  report.  As  shown  in  Figure  V-5  thru  V-7,  three  pages  of  output  are  produced 
for  each  value  of  the  aggregation  index  K.  Figure  V-5  illustrates  the  first  of  these 
three  pages  for  an  LRU  at  a  base  facility  (aggregation  index  K  =  1).  This  page 
displays  the  receipts,  returns,  shipments,  ordering  actions,  and  requisitions  asso¬ 
ciated  with  LRUs  at  base  level  during  the  simulation  run.  As  shown  in  the  figure, 
these  statistics  are  given  by  quarter,  and  results  are  shown  both  in  terms  of  number 
of  actions/FSNs  involved,  the  number  of  units  associated  with  these  actions,  and 
the  dollar  values  of  these  units. 

Figure  V-6  illustrates  the  second  page  of  the  three  page  output  associated 
with  the  aggregation  index  K  =  1.  This  page  records  the  number  of  expediting, 
rationing,  disposal,  and  termination  actions  that  were  recorded  in  the  simulation 
run,  as  well  as  the  number  of  reparable  generations,  condemnation,  and  NRTS 
actions  perfromed.  The  final  columns  of  this  page  record  the  number  of  repairs 
completed  within  each  quarter,  the  number  of  assets  that  in  a  work-in-process 
status  at  the  end  of  each  quarter,  and  the  total  number  of  days  that  assets  spent 
waiting  for  parts. 

Figure  V-7  illustrates  the  third  page  of  statistics  output  for  the  aggregation 
index  K  =  1.  This  page  records  the  supply  performance  observed  during  the 
simulation  run.  Values  for  end  of  period  backorders,  backorder  days,  inventory 
weeks,  and  observed  fill  rates  by  priority  class  are  displayed  on  this  page  of  the 


Figure  V-5 
Column  Definitions 

Column  Statistics  Definition 

(1)  INVOH  Inventory  on  hand  at  the  end  of  the  quarter 

(2)  INVOR  Total  quantity  on  order  at  the  end  of  the  quarter 

(3)  IRECET  Receipts  of  replenishment  orders 

(4)  IRETRN  Serviceable  returns  from  customers  of  the  supply  system 

(5)  ISHIPT  Total  shipments  to  fill  new  customer  requisitions  or  to  fill 

backorders 

(6)  ISHIPI  Total  shipments  to  fill  priority  1  requisitions  or  backorders 

(7)  IORDER  Total  replenishment  orders  initiated 

(8)  IREQT  Total  requisitions  received 

(9)  IREQC  Total  outstanding  backorders  that  are  cancelled  by  the 

customer 


(10)  IREQI  Total  priority  1  requisitions  received 
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Figure  V-6 
Column  Definitions 


Column  Statistic  Definition 


(11)  IEXPED  Total  expediting  actions  initiated 

(12)  IRATON  Total  of  all  rationing  actions  within  the  period 

(13)  IDISPS  Total  disposals  within  the  period. 

(14)  ITERM  Total  terminations;  i.e.,  totals  for  all  replenishment  orders 

that  are  cancelled  or  reduced  when  the  inventory  position 
exceeds  the  termination  level 

(13)  IREPGN  Total  number  of  reparable  generations  in  the  current 

period 

(16)  ICNDEM  Total  number  of  reparable  generations  condemned  in  the 

current  period 

(17)  INRTS  Total  number  of  NRTS  actions  taken  in  the  current  period 

If  the  stocking  location  is  a  base  or  the  Aircraft  Overhaul 

Facility,  this  column  represents  assets  which  are  trans¬ 
ported  from  that  location  to  the  depot.  If  the  stocking 
location  represents  the  depot,  this  column  represents  NRTS 
assets  received  within  the  current  period. 

(18)  IRECPL  Total  number  of  assets  which  completed  repair  within  the 

current  period. 

(19)  IWIP  Toted  number  of  assets  which  are  in  a  work- in- process 

status  at  the  end  of  the  period. 

(20)  IWFP  Total  number  of  days  spent  waiting  for  parts  in  the  current 

period.  This  time  is  not  recorded  until  an  LRU  is  removed 
from  the  wait-for-parts  status. 


HTlh  I  «  (  *  <n<»t3H 


Figure  V»7.  Sample  LRU  Summary  Report,  Page 
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Figure  V-7 
Column  Definitions 


Column 

Statistic 

Definition 

(21) 

IBACKT 

Total  backorders  outstanding  at  the  end  of  the  period. 

(22) 

IBACKI 

Total  priority  1  backorders  outstanding  at  the  end  of  the 
period. 

(23) 

IBAKDT 

Total  backorder-weeks  observed  during  the  period.  For 
example,  if  one  item  has  a  single  requisition  for  12  units  in 
a  backorder  status  for  3  weeks,  there  are  three  requisi¬ 
tion-weeks  of  backorders,  and  three  X  12  =  36  unit- weeks 
of  backorders  for  that  item. 

(24) 

IBAKDI 

Total  backorder-days  observed  for  priority  1  requisitions. 

(25) 

INVDAY 

Total  number  of  inventory-weeks  observed.  If  there  are  15 
units  on  hand  for  the  first  8  weeks  of  a  quarter,  and  6  units 
on  hand  for  the  remaining  four  weeks,  a  total  of  (15  X  8  +  6 
X  4)  =  144  inventory  unit-weeks  were  observed  in  the 
period. 

(26) 

IFILLT 

Total  number  of  requisitions  that  were  filled  "off-the- 
shelf,  i.e.,  that  were  filled  without  backordering. 

(27) 

IFILLI 

Total  fills  for  priority  1  requisitions. 

(28) 

IFILLT/ 

IREQT 

Fill  rate  for  the  period  based  upon  the  totals  of  all 
requisitions  received. 

(29) 

IFILLI/ 

IREQI 

Priority  1  fill  rate. 
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As  noted  above,  the  aggregation  index  K  may  take  on  six  distinct  values,  and 
three  separate  statistics  pages  are  produced  for  each  of  these  indices  --  a  total  of 
18  pages  of  output  statistics  for  each  Buy  5 import  Objective.  Figure  V-9 
illustrates  the  first  of  the  three  output  statistics  pages  associated  with  an 
aggregation  index  K  =  2.  This  index  records  results  associated  with  SRUs  at  base 
level.  This  report  has  the  same  format  as  for  the  case  when  K  =  1,  and  will  not  be 
discussed  further  here. 

Short-Form  Summary  Report.  Because  of  the  very  large  volume  of  printout 
associated  with  the  Detailed  Summary  Report,  the  user  will  usually  find  it 
desirable  to  develop  a  specialized  output  report  designed  for  the  needs  of  the 
specific  project  in  which  he  is  involved.  Figure  V-9  illustrates  the  format  of  a 
report  which  might  be  developed  in  this  effort.  This  figure  displays  totals  of  six 
major  categories  of  performance  statistics.  The  report  displays  the  number  of 
requisitions  which  a  given  stocking  location  submits  to  suppliers  of  that  location, 
the  total  amount  of  time  spent  waiting  for  parts,  the  number  of  backorder  weeks 
observed  in  filling  requisitions  submitted  to  that  supply  organization,  and  the  total 
number  of  requisitions  which  customers  of  the  organization  submitted.  The  total 
number  of  these  requisitions  which  were  filled  off  the  shelf,  and  the  corresponding 
fill  percentage  is  also  displayed.  Separate  statistics  are  printed  for  each  value  of 
the  aggregation  index  K,  as  well  as  totals  for  each  category.  Figure  V-S  illustrates 
statistics  expressed  in  units  (3  =  2);  however,  the  Short-Form  Report  has  three 
pages,  one  page  for  each  of  the  three  possible  values  of  the  measure  type  index  3. 

Quarter  Totals  and  Punched  Card  Output.  To  facilitate  statistical  analysis  of 
RIME  simulation  results,  the  values  of  10  major  statistics  are  punched  on  cards  by 
subroutine  ITRSLT  at  the  conclusion  of  each  BSO  evaluation  replication.  Record 


KJ Lt 


Form  Report 
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Code  FI  in  Appendix  A  defines  the  format  of  these  output  cards,  and  the 
FORTRAN  variable  names  used  to  produce  them.  In  addition,  the  punch  card  data 
is  also  printed  to  Logical  Units  15  and  16.  As  shown  in  Figure  V-10,  the  report 
printed  to  Logical  Unit  15  displays  totals  of  activities  for  the  first  S  quarters  of 
the  simulation  for  depot  buy-dollars,  depot  backorders,  base  fills,  base  requisitions, 
and  base  backorder -days  for  both  LRUs  and  SRUs.  The  first  column  of  Figure  V-10 
presents  the  number  of  the  Buy  Support  Objective  used  in  the  stock  level 
computations,  while  the  second  column  of  the  figure  displays  the  replication 
number  associated  with  the  output  statistics.  Observe  that  the  LRU  and  SRU  base 
requisitions  (IREQT)  are  identical  in  each  of  the  10  runs  shown  in  Figure  V-10. 
This  is  because  the  Exogenous  Events  Generator  forces  an  identical  number  of 
reparable  generations  in  each  replication  of  the  simulation  model.  Note,  however, 
that  the  buy  dollars  and  other  support  statistics  change  for  varying  values  of 
MLAM  and  different  replications,  reflecting  increasing  buy  dollars  and  support 
effectiveness  for  increasing  values  of  MLAM,  and  varying  support  performance 
within  replications  for  a  given  value  of  MLAM. 

Figure  V- 1 1  displays  the  report  printed  to  Logical  Unit  16.  This  report  is 
identical  in  format  to  that  of  Figure  V-10.  However,  this  report  provides  the 
totals  of  statistics  accumulated  over  the  entire  16  quarter  simulation  period. 

Debugging  Aids.  As  noted  above,  the  user  may  specify  values  for  several 
debug  flags  to  assist  in  the  development  of  new  RIME  routines.  Figure  V-12 
illustrates  outputs  obtained  when  the  flags  IEBUG  and  IDBUG  are  set  to  1. 

1EBUG.  When  IEBUG  =  1,  all  item  data  input  from  the  Exogenous  Event  File  is 
printed.  A  sample  of  the  printout  is  shown  at  the  top  of  Figure  V-12.  The  specific 
variables  printed  correspond  exactly  to  the  variable  names  shown  for  the  Item  Data 


figure  V-ll.  Logical  Cnit  16  Report. 
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Record  (Record  Code  B2)  presented  in  Appendix  A.  Basically,  these  variables 
display  unit  cost  and  time  delay  values  associated  with  each  LRU  and  SRU. 

IDBUG.  When  IDBUG  =  1,  an  information  line  is  printed  whenever  events  are 
entered  or  removed  from  the  Future  Events  List,  or  whenever  there  are  changes  in 
the  backorder  or  Work-in-Process  Files.  As  illustrated  in  Figure  V-12,  when 
IDBUG  =  1  the  subroutine  INGASP  prints  the  dimensions  used  to  initialize  the 
Work-in-Process  file.  The  next  six  lines  show  details  of  event  transactions  being 
placed  on  the  F.E.L.  by  subroutine  INITAL  through  calls  to  subroutine  ENTER.  The 
list  of  events  on  the  F.  E.  L.  at  time  0  is  also  printed  when  IDBUG  =  I. 

The  above  discussion  concerned  the  entry  of  event  notices  onto  the  F.E.L.  The 
bottom  of  Figure  V-12  illustrates  the  information  printed  when  an  event  is 
removed  from  the  F.E.L.  As  shown  in  the  figure,  at  time  0,  a  type  13  event  is 
removed  from  the  F.E.L.,  while  at  time  1  (ITIME  =  1),  an  Initial  Provisioning  Event 
(ITYPE  s  20)  is  removed  from  the  F.E.L. 

Stock  Status  Trace  Report.  When  IDBUG  =  1,  the  Stock  Status  Trace  Report 
is  produced  on  logical  unit  52.  The  first  5  columns  of  this  report  display  the  event 
time  (ITIME),  the  event  type  (ITYPE),  and  the  three  event  parameters  (IP1,  IP2, 
and  IP3).  The  remaining  columns  display  the  status  of  stock  on  hand,  on  order, 
work-in-process,  and  backordered  at  the  time  each  event  is  removed  from  the  F. 
E.  L.  These  values  are  displayed  by  Stock  Keeping  Unit.  Values  for  the  first  8 
SKUs  are  displayed  on  the  first  line,  and  any  additional  SKU  values  are  displayed  in 
subsequent  groups  of  8  on  following  lines. 

ITRACE,  ISTRAC.  At  times  the  analyst  will  not  want  to  produce  the  many 
lines  of  print  that  result  when  IDBUG  =  1,  although  he  may  be  interested  in 


SKU=1  SKU=2  SKU=3  SKU=4  SKU=5  .  SKU=6  SKU=7  SKU=8 


Figure  V-13.  Sample  Stock  Status  Trace  Reprot 


obtaining  event  printouts  during  a  specific  time  interval  in  the  simulation.  The 
flags  ITRACE  and  ISTRACE  provide  this  capability.  The  variable  ITRACE 
specifies  the  point  in  simulated  time  that  a  detailed  trace  of  simulation  of  events 
is  the  start.  At  that  point  in  time,  the  flag  IDBUG  is  set  equal  to  1.  This  causes 
the  event  by  event  printout  to  start.  The  flag  remains  equal  to  1  until  the 
simulated  clock  time  1STRAC.  At  this  time,  IDBUG  is  reset  to  zero,  and  the  event 
by  event  printouts  cease. 
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